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INTRODUCTION 


This  document  is  a transcription  of  an  audio  recording  of  presentations  and  discussions  from  the 
Second  NIST  Workshop  on  the  Development  of  Machine  Tool  Performance  Models  and  Data 
Repository.  This  workshop  is  the  follow  up  of  the  first  workshop,  which  was  held  on 
September  17,  1996  to  identify  the  needs  of  the  U.S.  industry  in  this  area  and  prioritize  the  tasks 
necessary  to  accomplish  the  goals  of  this  project.  The  purpose  of  the  second  workshop  is  to 
review  the  progress  taken  place  since  the  first  workshop  and  identify  any  modifications  to  the 
plans  based  on  the  industrial  partners’  input.  There  are  series  of  presentations  by  NIST  staff  as 
well  as  by  industrial  and  academic  collaborators  describing  the  work  being  done  to  develop  and 
use  machine  tool  performance  models  and  data  repositories.  The  discussions  that  took  place 
during  the  workshop  were  also  transcribed  in  detail  in  this  document  to  provide  accurate 
information  about  the  decisions  taken  and  their  justifications.  A summary  of  the  presentations 
and  discussions  was  also  provided  at  the  end  of  the  proceedings. 


DISCLAIMER 


Certain  trade  names  and  company  products  are  mentioned  in  the  text  or  identified  in  an 
illustration  in  order  to  adequately  specify  the  procedures,  software,  equipment,  and  tools  used.  In 
no  case  does  such  identification  imply  the  recommendation  or  endorsement  by  the  National 
Institute  of  Standards  and  Technology,  nor  does  it  imply  that  the  products  are  necessarily  the  best 
available  for  the  purpose. 
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WELCOME  AND  INTRODUCTION 


MR.  BLOMQUIST:  I’d  like  to  welcome  you  to  the  Machine  Tool  Performance  Models  and  Data  Repository 
Workshop.  This  project  is  a collaboration  between  us  and  industry.  Therefore,  we  do  appreciate  you 
coming.  What  we’d  like  to  do  is  to  have  an  actual  working  workshop,  and  get  as  much  industrial  input  as 
much  as  possible.  We,  therefore,  have  presentations  by  Boeing,  Livermore,  Caterpillar,  Automated 
Precision,  Inc.,  Independent  Quality  Laboratories  and  others.  Furthermore,  we’d  like  to  have  an  exchange 
of  ideas  and  information. 
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MACHINE  TOOL  PERFORMANCE  and  MACHINE  DATA  REPOSITORY 

PROJECT  SUMMARY 
A.  Donmez 

We  at  NIST  are  trying  to  develop  machine  tool  performance  models  and  a machine  data  repository.  This  is 
a part  of  our  National  Advanced  Manufacturing  Testbed  (NAMT)  Program  at  Manufacturing  Engineering 
Laboratory  (MEL)  at  NIST.  The  NAMT  Program  at  MEL  is  an  effort  to  develop  new  tools  and  to  find  new 
solutions  to  the  standards  and  metrology  issues  raised  by  the  information-based  manufacturing. 

The  NAMT  program  started  last  year  with  four  projects.  The  first  one  is  the  project  that  we’re  working  on 
and  we  re  going  to  be  talking  about  today  and  tomorrow.  It  is  the  development  of  machine  tool  performance 
models  and  machine  data  repositories.  The  other  three  projects  within  this  program  are: 

Characterization,  simulation  and  remote  access  of  parallel  structured  machine  tools. 

Frameworks  for  discrete  part  manufacturing,  and  finally. 

Development  and  manufacture  of  atom-based  standards. 

In  the  very  near  future,  there  will  be  other  projects  initiated  within  the  NAMT  Program. 

If  distributed  manufacturing  is  going  to  be  the  major  thrust  in  the  future,  we  have  to  have  better  coordination 
and  resources  for  information-based  manufacturing.  In  addition,  prototyping  and  evaluation  of  the 
manufacturing  capabilities  are  becoming  major  issues,  therefore  we  must  have  some  tools  that  are  ready  for 
the  implementation  of  distributed  manufacturing  and  reducing  the  time  to  market  in  prototyping  efforts. 

The  problem  with  the  current  state-of-the-art  in  new  product  introductions  and  prototyping  is  that  it  is 
basically  an  iterative  one.  You  start  with  a new  part  design,  and  then  from  that  you  start  testing  some  of  the 
processes  and  some  of  the  machines  in  your  plant  in  order  to  find  out  if  you  can  make  that  part.  If  you 
cannot,  then  you  go  back  and  change  your  plans  and  change  your  machines  until  you  find  a satisfactory  part 
that  you  can  make  with  available  resources  that  you  have.  Then  you  go  through  the  inspection  of  this  part 
and  find  out  whether  you  can  really  inspect  this  part  for  the  capability.  You  go  through  this  iterative  process 
until  you  fine  tune  your  production  and  then  start  doing  the  actual  parts.  In  general,  this  whole  process  takes 
somewhere  between  2-3  years.  We  talked  with  major  manufactures,  like  Boeing,  Caterpillar  (where  we  have 
representatives  here)  and  their  basic  claim  is  that  it’s  too  expensive  to  go  through  this  iterative  process.  We’re 
looking  for  ways  to  decrease  this  time  and  decrease  this  cost,  by  taking  some  of  this  physical  activity  into 
the  computer  domain  so  that  instead  of  cutting  the  part,  we  start  with  cutting  bits,  and  then  analyze  all  this 
information  before  we  actually  start  the  cutting. 

In  order  to  be  able  to  do  this  type  of  activity,  we  need  a lot  of  resources  to  enable  us  to  carry  out  this  whole 
prototyping  effort  in  the  computer  domain.  These  resources  include  predictive  machine  and  process  models, 
reliable  machine  capability  data,  and  accurate  environmental  and  material  specifications.  How  can  we  make 
sure  that,  when  we  simulate  the  operation  in  our  computer  models,  we  can  get  realistic  parts  out  of  that 
simulation?  How  can  we  represent  the  performance  of  the  machine  in  a realistic  form  in  our  computers  so 
that  we  can  get  that  information  out  of  that  model?  And  how  can  we  really  incorporate  the  environmental 
information  on  our  machine  tools,  our  equipment,  located  in  our  factory  environment,  and  how  can  we 
incorporate  that  information  into  our  models  and  therefore  into  other  parts?  These  are  basic  ideas  that  we 
are  trying  to  get  ourselves  prepared  to  handle  in  our  computer  models.  A big  step,  of  course,  in  achieving 
this  type  of  prototyping  is  going  to  be  the  repository  that  we  will  talk  about  today  and  tomorrow. 
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Last  September  we  prepared  a very  limited  demonstration,  to  see  what  we  could  do  and  what  we  would  need 
in  order  to  accomplish  this  virtual  prototyping  effort.  We  started  with  a Computer  Aided  Design  (CAD)  and 
a computer  model  of  one  of  our  machines.  Based  on  the  CAD  design,  we  generated  the  realistic  description 
of  part  geometry  by  calculating  the  actual  tool  path  using  the  machine  model.  At  the  same  time,  we  used  our 
machine  to  make  the  actual  parts  and  compare  these  parts  with  the  calculated  part  geometry.  One  is  the  real 
part,  the  other  is  the  virtual  part.  We  also  tried  to  identify  what  problems  are  associated  with  this  type  of 
implementation. 

We  used  a commercial  solid  modeling  package  to  describe  the  virtual  part.  However,  we  had  to  manipulate 
some  functions  of  the  package  in  order  to  show  the  actual  shape  of  the  part.  Whiskers  are  plotted  on  top  of 
the  nominal  geometry.  We  have  the  same  thing  corresponding  to  actual  measurements,  which  are  again 
superimposed  on  the  nominal  part  geometry.  Now,  if  you  were  to  show  a more  realistic  part,  then  we  would 
have  to  have  a lot  of  data  points  around  this  nominal  geometry.  That  is  becoming  a problem  because,  to  be 
able  to  even  show  this,  we  had  to  play  a lot  of  tricks  about  defining  new  features  for  each  of  these  whiskers. 
Likewise,  to  be  able  to  show  the  positive  and  negative  errors,  we  had  to  go  through  a lot  of  trouble.  We 
would  like  the  software  developers  to  give  us  the  tools  to  be  able  to  represent  these  parts  more  realistically, 
not  only  the  nominal  parts,  but  the  actual  parts  that  would  be  coming  out  of  the  simulation  like  this. 

We  have  identified  our  challenges  in  order  to  be  able  to  do  this  virtual  prototyping  effort.  We  definitely  need 
virtual  machining  and  inspection  modules  that  can  be  implemented  in  existing  CAD  packages  or  new  CAD 
packages.  We  need  to  have  information  models  representing,  comparing,  and  computing  all  this  machine- 
related  data.  We  also  need  distributed  repositories  allowing  many  people  to  access  to  this  information  for 
different  purposes.  We  are  now  going  to  be  concentrating  on  the  repository  and  the  information  models. 
Eventually,  well  move  onto  these  virtual  machining  and  inspection  modules  in  our  project. 

QUESTION:  You  mentioned  the  software  package  for  solid  modeling.  Which  package  was  that? 

MR.  DONMEZ:  The  machine  model  is  implemented  in  ADAMS  to  do  the  kinematics  of  the  machine,  but 
the  solid  model  itself  is  generated  in  Pro-E  and  transferred  over  to  ADAMS.  The  parts  themselves  are  all  in 
Pro-E.  The  company  that  owns  ADAMS  is  called  Mechanical  Dynamics  and  the  company  that  owns  Pro-E 
is  called  Parametric  Technologies.  These  are  just  samples  of  software  packages  that  you  can  use. 

QUESTION:  The  last  chart  that  you  showed,  before  we  asked  the  questions,  you’d  mentioned  modules.  Is 
each  of  these  software  packages  related? 

MR.  DONMEZ:  Yes.  We  re  thinking  about  these  as  software  packages  that  you  could  incorporate  into 
existing  CAD  packages,  for  example.  What  we’ve  done  in  this  concept  demonstration  is  to  take  ADAMS 
and  we  put  some  of  the  modeling  that  we  used  to  do  on  these  machines  into  this  ADAMS  model,  but  it  was 
a very  crude  way  of  incorporating  the  models  into  these  existing  models.  We  want  to  have  more  capability, 
generic  capability,  to  be  able  to  put  machine  models,  process  models,  into  these  CAD  systems. 
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REVIEW  OF  LAST  WORKSHOP 
A.  Donmez 

We  had  the  first  workshop  in  September  17,  1996,  in  Gaithersburg,  MD.  Its  purpose  was  to  identify  what 
are  the  industry’s  needs  and  what  we  are  expected  to  do.  We  wanted  to  establish  if  it  would  be  necessary 
to  get  involved  in  these  types  of  activities. 

We  had  presentations  by  industry  and  academia.  Industrial  needs  on  machine  selection  capability, 
suppliers’  capability,  make-by  decision  tools,  simulation  tools,  capacity  planning  and  maintenance 
planning  were  all  reiterated  in  that  workshop. 

We  also  look  at  academia  as  a partner  in  this  type  of  program,  and  their  needs.  They  want  to  have  some 
collaboration  tools  in  research  and  development  of  machine  tools  and  manufacturing  processes.  They 
need  tools  to  handle  and  share  between  multiple  researchers,  as  well  as  large  amounts  of  data  on  machine 
tools  to  generate  and  test  machine  tool  models.  By  the  introduction  of  the  ANSI/ASME  B5.54  and  B5.57 
standards,  more  and  more  people  are  measuring  their  machines  and  this  data  is  becoming  available. 

There  are  new  measurement  systems  that  are  inexpensive  to  collect  data  on  machine  tools  and,  with  that 
kind  of  environment,  we  need  to  have  structured  tools  to  be  able  to  collect  and  analyze  and  identify  some 
of  the  machine  performance  characteristics.  In  addition,  of  course,  they  want  to  have  apples-to-apples 
kind  of  comparison  between  the  different  types  of  data-sets. 

The  consensus  among  and  a basic  conclusion  made  by  the  people  who  participated  in  that  workshop 
based  on  one  full  day  of  discussions  in  September,  was  that  NIST  should  be  leading  the  effort  to  develop 
both  structure  and  contents  of  a database  to  be  eventually  spun  off  to  private  enterprise.  We  were 
planning  to  work  on  these  problems,  but  we  want  to  be  sure  that  we  have  the  industry’s  support.  With 
that  kind  of  result,  we  felt  much  more  comfortable  to  continue  the  work  that  we  were  planning  to  do. 

Listed  here  are  several  comments  from  that  workshop.  One  of  them  says,  "Whatever  the  repository  is,  it 
should  have  some  hierarchical  nature."  [In  other  words,  some  people  will  need  a small  amount  of  data, 
and  some  people  will  need  more  detailed  data,  more  detailed  models,  so  it  has  to  be  hierarchical  or  a 
layered  structure.]  If  you  want  a few  numbers  just  to  represent  your  machine,  you  should  not  go  into  too 
much  detail  in  this  structure.  The  hierarchical  nature  will  allow  you  to  be  able  to  pick  the  level  of 
complexity  of  your  data  structures. 

Participants  of  the  workshop  also  stated  that  it  should  have  a graphical  representation  capability  along 
with  the  numerical  information. 

Another  point  was  that  we  should  use  commercially  available  relational  databases  as  much  as  possible, 
and  that's  also  our  philosophy  in  any  development  we  do. 

One  other  item  of  real  concern  was  that  there  is  a mechanism  needed  to  weed  out  bad  data.  So  many 
people  are  collecting  a lot  of  data  and,  if  we  put  all  the  data  in  the  same  repository,  there  has  to  be  some 
way  of  finding  out  the  bad  data  and  to  weed  it  out.  That's  a difficult  issue  and  we  need  to  discuss  that 
later  on  today. 

Further  comments  were  made  on  the  overall  direction  of  the  project.  One  of  them  was  the  indication  that 
we  need  an  industrial  consensus  about  basic  components— standards,  simulation  tools,  software  models— 
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and  I think  that’s  an  important  issue.  Another  related  item  is  the  need  for  cross-sectional  representation 
by  industry,  which  are  automotive,  machine  tool  builders,  small  shops.  We  were  lacking  representation 
of  these  industries.  We  have  done  some  work  in  order  to  generate  some  interest  in  the  part  of  the 
industry,  but  this  is  still  an  ongoing  effort  on  our  part. 

Another  issue  that  was  emphasized  is  that  private  industry  should  develop  the  third  party  software  tools. 
We  have  some  software  developers  among  us  today  to  discuss  that  with  us. 

There  were  some  further  comments.  There  is  a need  to  write  a specification,  devise  prototypes,  test 
prototypes  and  franchise  our  whole  operation  in  real  life.  In  order  to  accomplish  these,  we’ve  been 
working  since  September  to  write  some  specifications,  some  data  formats.  We  also  worked  on  some 
prototypes  that  well  show  you  along  with  the  testing  on  them.  Hopefully,  well  get  some  idea  where  we 
are  going  in  the  prototyping  issue. 

We  should  start  coordinating  with  national  and  international  standards.  Our  original  schedule  was  that 
we  would  finish  all  the  development  and  then  go  for  standardization  processes.  But,  a suggestion  was  to 
start  thinking  about  standards  early  on  so  that  they  will  be  ready  when  we  complete  this  stage  of  our 
work.  Therefore,  we  started  heading  in  that  direction.  And  as  you'll  see  in  Simon  Frechette’s 
presentation  on  the  EXPRESS  models  to  be  able  to  incorporate  this  type  of  activity  within  the  STEP 
standard’s  framework. 

Another  item  was  to  completely  digitize  the  description  of  parts  without  drawings,  and  we  are  going  to 
have  some  discussion  on  that.  We  need  standardized  simplistic  models  to  produce  data  to  characterize 
machines. 

Those  were  some  important  comments  that  we  heard  at  the  last  workshop,  and  we're  going  to  try  to 
address  some  of  those  comments  today  and  tomorrow  morning. 
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OBJECTIVES  OF  THIS  MEETING 
A.  Donmez 


Based  on  all  this  input  that  we  had  from  our  first  workshop,  we’ve  worked  on  the  definition  of  the  data 
requirements  and  data  formats  among  ourselves  at  NIST.  We  developed  some  documents  that  we  will  be 
going  over.  Also,  we’re  going  to  show  you  the  experimental  Web  repository  that  we  developed  based  on 
these  types  of  data  formats.  We’ll  show  you  what  the  problems  are  and  what  we  can  do  with  these  types 
of  Web  repositories.  In  this  meeting,  we  hope  to  come  to  some  conclusion  and  agreement  on  the  set  of 
data  requirements  and  formats  [demonstrate  the  repository].  We  hope  to  receive  your  comments  on  any 
modifications  that  may  make  it  more  useful,  and  we’d  like  to  initiate  some  discussion  on  the  simulation 
tools.  I'm  sure  we’re  not  going  to  be  able  to  conclude  the  discussion  on  the  simulation  tools,  but  at  least 
we  should  have  some  idea  where  we  are  going  and  what  type  of  industrial  development  we  need  in  order 
to  satisfy  our  goals. 

I'd  like  to  also  remind  everybody  the  critical  issues  that  we're  trying  to  answer  in  this  project.  Eventually 
we  need  this  relationship  between  the  machine  data  and  the  machined  parts.  There  is  a lot  of  machine 
data  available,  and  a lot  of  data  on  machined  parts,  but  the  correlation  between  the  machine  data  and  the 
machined  parts  is  a significant  problem  that  we  need  to  resolve.  We  also  need  to  resolve  the  issue  of  the 
interim  fast  machine  checks  and  their  relationship  to  cutting  performance.  We  also  have  to  allow  our 
repositories  to  have  information  in  it  such  as  requirements,  data  types,  and  formats.  I think  that  the  main 
goal  for  this  meeting  is  to  address  the  critical  issues  of  information  exchange  mechanisms,  structures  and 
standards. 

Now,  we're  going  to  hear  some  industrial  presentations  to  set  the  stage  for  the  discussions  in  the 
afternoon.  We  have  a presentation  by  Loyd  Bishop  from  Boeing.  He  is  going  to  talk  about  his  efforts  in 
machine  characterization  and  Boeing’s  ideas  of  how  to  use  these  types  of  data.  Debbie  Krulewich,  from 
Lawrence  Livermore  National  Laboratory  (LLNL),  will  talk  about  their  efforts  in  machine  modeling. 
Professor  Steve  Patterson,  of  the  University  of  North  Carolina  at  Charlotte  (UNCC),  is  going  to  give  us  a 
little  bit  of  his  insight  on  what  we  need  in  these  types  of  data  repositories.  Vivek  Chandrasekharan,  from 
Caterpillar,  will  talk  about  Caterpillar's  activities.  Quan  Ma,  from  Automated  Precision,  Incorporated 
(API),  will  talk  about  a new  instrumentation  that  they  tried  on  machine  tool  metrology.  Buzz  Callaghan, 
from  Independent  Quality  Labs  (IQL),  is  going  to  talk  about  an  overview  of  what  we  need  for  this  type  of 
repository. 
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INDUSTRY  PRESENTATIONS 


BOEING  COMMERCIAL  AIRPLANE  GROUP 
WICHITA  DIVISION 
L.  Bishop 


I have  a lot  of  documented  data  on  machines  that  I’ve  been  measuring  since  1992.  What  you  have  in 
front  of  you  is  a sample  of  some  of  the  work  that  I do  on  machine  characterization.  The  machine  we’re 
looking  at  is  one  that  I tested  in  January.  It’s  an  off-the-shelf  machine  which  costs  about  $100,000.  It’s  a 
very  good  machine,  which  we  got  with  the  intent  of  using  its  off-the-shelf  controller  first.  Then, 
eventually,  we  are  going  to  evaluate  the  new  Hewlett-Packard  open  architecture  controller  on  this 
machine  as  well  as  the  Renishaw  black  box. 

As  we  move  into  the  world  of  increased  production  schedules  and  part  acceptance  of  machine  tools,  I 
also  know  that  the  machine  tools  we  buy  today  are  much  more  accurate  than  they  were  20  to  30  years 
ago.  And  most  of  them  come  with  some  type  of  probing  system.  So  I’ve  been  working  with  Bruce 
Borchardt  and  Dr.  Steve  Phillips  at  NIST  on  some  ways  of  doing  some  in-process  metrology.  Not  only 
do  I characterize  the  machine  tool  initially,  but  we  would  like  to  go  out  and  do  some  in-process 
measurement.  These  evaluate  the  machining  center  as  a measuring  tool,  so  we  don’t  have  to  take  the  part 
off  and  let  it  go  into  its  relief  state.  I’d  like  us  to  focus  on  evaluating  our  machining  centers  as  measuring 
devices  also.  I think  we  need  to  work  on  that  a little  bit. 

The  first  test  I performed  on  this  machine  was  measuring  diagonal  displacements  by  laser  interferometer. 
I like  measuring  diagonal  displacements  because  they  look  at  all  the  sources  of  error  at  one  time.  This  is 
a 3-axis  machine.  The  tolerances  we  use  for  tooling  is  ± 250  micrometers(  10-thousandths)  and  for 
production  parts,  though  it  depends  on  the  part,  is  usually  ± 750  micrometers(30-thousandths). 

I document  everything.  You’ll  see  a sample  of  how  I document  everything  in  slide  6.  As  Jim  Bryan  and 
Jeff  Portas  pointed  out  several  years  ago,  random  results  are  the  consequence  of  random  procedures.  I 
can  duplicate  these  tests  tomorrow,  next  year,  and  five  years  from  now  and  hopefully,  if  I'm  in  a nice 
controlled  environment,  I'll  get  the  same  results.  I put  a mark  on  the  first  graph  in  slide  2 because  I like 
to  know  how  the  errors  propagate  in  the  diagonals  and  how  I can  look  at  what's  causing  those  errors.  If 
you  look  at  the  other  graphs,  you're  going  to  see  the  linear  displacement  errors  along  X axis  are  doing 
almost  the  same  thing  [slide  5.] 

The  next  test  I did  was  a drift  test  while  I went  home  [slide  4.]  Even  though  this  isn't  a production 
machine,  I like  to  do  drift  tests.  The  average  outside  temperature  on  that  morning  when  I came  in  was  15 
degrees,  so  it  was  rather  cold.  The  reason  that  I've  got  a shift  in  the  data  (around  6,000  seconds)  is 
because,  a few  hours  after  I started  this  drift  test,  the  power  failed.  The  hydraulics  went  down  with  it 
causing  the  machine  to  settle  down.  So,  I would  assume  that  if  the  power  had  not  gone  down,  it  probably 
would  have  stayed  and  been  rather  sinusoidal  within  about  5 micrometers(2  ten-thousandths)  for  the 
duration  of  that  drift  test. 

The  data  show  on  slide  8 is  from  an  X axis  incremental  test  and  it's  a drift  test.  I asked  the  machine  to 
move  the  smallest  increments  that  the  controller  is  capable  of  moving.  I asked  the  machine  to  go  a total 
distance  of  one-thousandth  of  an  inch  and  then  return.  So,  those  are  one  ten-thousandth  steps.  The 
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machine  has  very  little  backlash  seen  as  it  discontinuates  in  the  data  as  the  direction  of  motion  changes  . 
What  you  see  for  a backlash  in  the  X axis  is  right  up  at  the  top  of  it  when  it  completely  changes  direction. 

Slide  9 shows  the  X pitch  test.  If  I put  a mark  on  it,  it  will  fall  in  line  with  the  diagonals  and  the  X axis 
error.  So  in  some  cases  you  see,  I think  pitch  is  coming  into  play  as  well  as  the  X axis  error  on  the 
machine. 

Slide  1 1 shows  the  X axis  yaw.  All  of  the  graphs  are  labeled  down  in  the  bottom  right-hand  comers.  A 
lot  of  the  noise  in  the  data  was  due  to  vibration.  The  spikes  right  at  the  end,  are  due  to  the  inertia  when 
the  machine  is  first  starting  up.  Even  though  we  weren’t  moving  the  machine  fast,  when  it  comes  from  no 
movement  to  some  movement  you  can  see  a few  spikes  at  the  end.  So,  I would  say  I don’t  really  see  a 
problem  with  this  machine  when  the  bandwidth  is  4 arc-seconds.  Yet,  you’re  mainly  looking  at  about  1 
or  2 arc-seconds  in  that  machine  for  angular  error. 

Slide  13  shows  the  Z axis  linear  displacement  errors.  Slide  14  shows  Z incremental  tests  results.  You 
can  note  the  same  backlash  that  you  see  for  the  linear  in  Z apparent  in  this  smallest  increment  test.  For 
the  Z Incremental  Test,  I asked  the  machine  to  do  a one  thousandth  of  an  inch  move  out  and  back  with 
one  ten  thousandth  steps. 

The  Z axis  yaw  was  rather  minimal  as  shown  in  slide  16--  a bandwidth  of  1 arc-second. 

Slide  17  shows  the  Y axis  linear  displacement  errors.  They  look  rather  nice,  with  the  average  reversal 
error  being  less  than  2 ten-thousandths  of  an  inch. 

The  Y axis  incremental  test  [Slide  20]  also  looks  very  nice.  These  are  out  and  back  three  times,  telling 
the  machine  to  move  one  ten-thousandths  of  an  inch  up  to  one  thousandths  back. 

Slide  21  shows  the  Y axis  pitch  data  and  it’s  a very  small  number  also— 2 arc-seconds. 

Slide  23  shows  the  Y axis  yaw  data,  which  is  a small  number,  and  I also  see  the  same  kinds  of  trends  like 
I saw  in  my  diagonal  displacement  data. 

MR.  DONMEZ:  We  need  to  look  at  the  types  of  data  that  Loyd  is  presenting,  as  well  as  the  types  of 
plots  and  types  of  information  that  go  along  with  the  data.  Those  are  the  things  that  we  need  to  discuss  in 
the  afternoon.  Also,  I’d  like  to  emphasize  that  the  unambiguous  documentation  of  this  data  is  very 
important. 

MR.  PATTERSON:  A number  of  the  plots  you  have  displayed  non-repeatability  in  the  data.  That  non- 
repeatability can  come  either  from  the  machine  tool  itself  or  from  the  measuring  system.  Two  questions. 
Do  you  have  an  idea  of  which?  And  how  do  you  document  your  understanding  of  that  so  that  the  spread 
is  attributed  to  the  right  source? 

MR.  BISHOP:  No,  and  no.  I don’t  know  where  the  error  comes  in,  whether  it’s  in  my  measuring  system 
or  whether  the  non-repeatability  is  in  the  machine.  Since  my  tolerances  are  much  larger  than  the  spread 
of  the  data,  I don’t  really  care. 

MR.  CALLAGHAN:  In  your  X axis  yaw  plot,  you  have  that  area  where  you  have  the  data  circled  there. 
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When  you  present  this  information  to  somebody  how  do  you  explain  that  curve?  Do  you  just  hand  them 
the  graph  and  there  is  no  question  of  the  fact  that  we  have  that  spike  in  there? 

MR.  BISHOP:  The  spike  looks  somewhat  repeatable  to  me,  and  probably  because  of  the  initial  move  of 
the  machine.  That’s  what  I try  to  explain  to  them.  I would  say,  "Don’t  worry  about  that;  that’s  a very  nice 
machine." 

MR.  CALLAGHAN:  The  question  really  isn’t  raised  then  when  somebody  looks  at  that  data  set? 

MR.  BISHOP:  Probably  not,  because  that’s  a very  good  machine.  If  you  look  at  that  bandwidth,  the 
number  is  actually  exaggerated  because  you’re  looking  at  the  most  positive  and  the  most  negative 
extremes  there. 

MR.  DONMEZ:  If  the  machine  was  actually  bad— let’s  assume  your  scale  to  be  10  times  worse— how 
would  you  put  information  into  your  data  to  explain  these  things  from  the  point  of  view  of  repositories? 

MR.  BISHOP:  If  my  machine  were  10  times  that  bad  I’d  call  the  mechanics  in  there  and  tell  them  to 
straighten  it  out.  I mean,  if  it’s  angular  error  because  that’s  going  to  creep  into  the  picture  everywhere.  I 
don’t  know.  I don’t  have  a good  answer. 

MR.  CALLAGHAN:  One  of  the  reasons  why  I’m  raising  this  question  is  that  the  frequency  content  of 
this  data  is  incredibly  important.  If  you  look  at  the  frequency  of  that  particular  spike  and  say,  "Okay,  that 
frequency  is  associated  with  setup  errors,  and  not  necessarily  the  machine’s,"  we  could  then,  if  you  were 
going  to  put  it  in  the  repository  or  extract  it  say,  "This  is  not  important."  This  is  what  we  do  currently. 
Well  go  in  there,  but  before  we  present  the  data  to  somebody,  the  unwashed,  well  actually  modify  the 
data.  We  remove  that  spike,  make  a comment  and  say  we  have  removed  the  setup  errors  from  start  and 
finish.  Then  well  present  the  data  but  eliminate  that  question.  Maybe  we  can  discuss  it  later  this 
afternoon  because  it  was  one  of  the  issues  I had  with  this  data. 

MR.  BISHOP:  I’d  also  like  to  point  out  that  the  people  that  are  with  me  here,  Jim  Covington  and  Sue 
McMillan,  they  have  a lot  of  data  also.  Jim  goes  out  and  runs  periodic  ballbars  on  a lot  of  our  machines 
in  Wichita  to  ensure  that  they  haven’t  changed  or  that  they  haven’t  crashed  the  machine.  So,  if  any  of  you 
are  interested  in  how  he  does  that,  just  talk  to  Jim. 

MR.  HEMMERLE:  When  you  look  at  your  data,  you  take  an  evaluation  of  a machine,  are  you 
comparing  differences  between  evaluations?  Say  an  evaluation  in  June,  an  evaluation  in  September.  Are 
you  subtracting  or  doing  anything?  Are  you  looking  at  it  saying,  "This  is  what  I currently  have,"  and 
adjust  to  it? 

MR.  BISHOP:  That’s  a good  question.  This  machine  happens  to  be  in  a controlled  environment, 
meaning  there’s  not  so  much  cyclical  effect  depending  upon  our  four  completely  varying  seasons  in 
Kansas.  It's  also  probably  not  being  affected  thermally  like  a lot  of  the  machines  are  out  in  a hostile 
environment. 

MR.  HEMMERLE:  I'm  looking  at  accuracy  deterioration  tracking. 

MR.  BISHOP:  It  depends  on  what  they're  using  the  machine  for.  If  we're  doing  a lot  of  hogging  with 
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titanium  and  then  I see  a lot  of  wear  on  the  machine.  I’m  sure  Jim  sees  deterioration  when  he  runs  his 
ballbar.  In  that  case,  that  might  be  a good  tool  to  use  to  monitor  deterioration  to  raise  the  red  flag  and 
call  maintenance  in  to  change  the  roller  packs,  or  whatever  they  may  need  to  do. 
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Comment:  good  data,  uith  come  vibration 


• Pd^a/Po*:  1 Soacino: 

»Jth  60»«  vibration 


0.50 


Band  Width; 


4.7 


'Sc  01/14/97  12;  41 

'Gr  01/14/97  12:54 

Slide  ],9  'Cogent.*  oood  data.  w 


DIRECTION  - X* 


LIME  - 1“ 
POS~~  RUN  1 

AVC 

X 0.40000 
2 -0.60000 
5 0.50000 

4 O.BOOOC 

5 0.00000 

6 0. 100*0 
v -o.^oycw 

8 -<1.90000 

9 -0.60000 

© o.voooo 
X 1. loOOO 
2 1 OOOOO 

A O. 90<X*0 

4 1.50000 

5 1.6CXKK* 

6 l .30000 

7 1 .30000 

8 ? <.30000 

9 J.OCHpj,. 

*o  x . 9*XKK> 

1 1 .y*UOOO 

2 1.70000 

A r.iooco 
4 7 20000 

c*  1 

6 J 8*XX*0 

7 2.00000 

•*i  7.10600 

*9  A .90000 

<1  2.30000 

•»  *..60000 
■2  7.JOOOO 
•3  2. OOOOO 

-4  I .80**00 

:s  1 . 80000 

-6  . . I. 6**00© 

.7  * *1.60000 

8 2.00000 

.v  1.90000 

10  1.40000 

11  1.50000 

12  1.800CO 

•3  i.Soooo 

♦4  2.60000 

>5  2.40000 

lo  2.70000 
i7  2.20000 
^ 3-  lOOOO 

51  2.40000 

52  2.20000 

53  2.00000 

54  1.70000 

a. 90000 
2.10000 
1.60000 

1.50000 

1.50000 

2.00000 

2.50000 
1.00000 
1.20000 
1.80000 
2.40000 
2-30000 
3.00000 

3.30000 

3.10000 

3.20000 

1.90000 
2-50000 

2.30000 

2.10000 

I . 90*  XX) 

2.20000 
2.60000 
2.70000 

2.90000 
3.000©© 
3.20*»>O 

4 .2***©o 
4 .10*0* 

3 7*X4*U 
S./UU©© 

3 ‘XXkm» 


RUN  3 


55 


69 


*•7 


-0.60000 
-1.00000 
-0.0000* 
-1.20000 
-1.50000 
-1 . 70000 
-1.3C.CKXI 
-0-60000 
-0.90000 
0.30000 
0.9OC«OO 

xlbiwoo 

1.2DOOC 

0.90000 

u.9 oooo 

0. 00000 

0 4»*OO0 

i. ooooo 

1. TOUOO 
0.30000 
1. 5<XKX) 
1.7*000 
1-30000 
1-300*0 

1 . OOlXrO 
1.10000 
0.70000 
1.20000 
2.10000 
1.50000 
1. 40000 
1.50000 
1.70000 

2. 10000 
1.50000 

i.oootxt 

0.50000 

1.40000 

1.40000 

1.80000 

1.70000 
1-20000 
0-90000 
1.40000 
2.30000 

2.70000 
2.30000 

1.10000 


ltx>- 

too 

tos 

tOo 


3.  7 txiox 
NOOut 

-.CoOOt* 

2 8**0<Ki 
3 . 1 0<X>* » 

7 .3©Oi«» 
£.40000 
70000 
3.8**000 
4 .1*0000 
-’..3**000 

4 . 70000 
3. 7CXnx> 
a . 40000 
3.  7<XX>0 
4.20000 
4.500©** 
5.  lOOOO 
4 . V©**©** 
4.5CKK4J 
3 . 'XXXXD 
3. 90**** 

3 - H**o»«-> 

4 

2.90000 

3.30000 


-0.10000 
-0.90000 
-1.50000 
-1  80000 
-2 .40000 
-1.20000 
-*-.9**000 
-0.50000 
-0-80000 
-1.10000 
-1-70000 
*1.10000 
- 1.50000 
-0.90000 
-0.90000 
-0.20000 
-0.30000 
-0.60000 
l>.400*XJ 
1.40000 
1.20000 
-O .lOOOO 
0.10000 
0.20000 
0.40000 

o.noooo 

-0-30000 

-0.70000 

-1-00000 

-0.40000* 

-0-20000 

0.30000 

0.50000 

1.20000 

1.30000 

0.6000C 

1.30000 

1.80000. 

1.60000 

1.40000 
1.70000 

1.70000 
1.80000 
2.20000 

2.40000 

2.70000 
1.90000 
2.40000 


1.30000 

1.30000 

1.70000 

1.70000 
2.10000 
1.60000 
2.10000 

1.30000 
2.60000 
1.80000 
0.50000 

1.40000 
2.60000 

3.30000 
3.50000 
2.90000 

3.40000 
3-50000 
3.50000 
3.20000 
3-30000 

3.30000 
2.90000 
3.40000 
3.40**00 

2.70000 

2. 90000 

3.60000 
3.  6000** 
5.300**0 
3.600»XJ 

3-Soooo 
3.3004*0 
3. 40000 
A . 3t*XX> 

A 9T4XJO 
A 6&XMK> 

3.90000 
4 70000 
3 70000 
% 'JJOOO 
a *4*000 
3.-4000** 

4.30000 

3.00000 

4.70000 
4.80000 

5. 00000 

5.30000 

4.90000 
S.SOOOu 
3 . 30000 
5.40004) 
3.70000 
6.10000 
6.50000 

7.20000 

7.10000 

6. 10000 

5.90000 

4.20000 
4.41*000 
4. 70046/ 
4 . IOO0O 
3.80000 

3.20000 


0.60000 
O. 70000 
-0.10000 
-1.00000 
©. OoOOO 
1.00000 
1-40000 
1.80000 
1.2000** 
-0.20000 
-0.70000 
-0.40000 
-0.60000 
-O.  *»0»t00 
O . lOOOO 
0.50000 
O.SOCHX) 
.1.  44*000 
1-4000© 

1 . 50000 
.1.60000 

1.40000 
1.00000 
0.2000© 
0.700*0 
0.70000 

-0.30000 

0.30000 

0.80000 

2.30000 

2.800>0 

2.60000 

2.50000 

2.40000 
2. 70000 
2.70000 

2.60000 
3.00000 
2.30000 

2. 10000 

3.40000 
2.90000 
2.30000 

2.10000 
1.20000 

1.60000 

7.50000 

2 .400**0 


1.80000 
2.  lOOOO 
2.30000 
2.80000 
2.30000 
2.30000 

2.50000 
2.30000 

1.50000 

1.50000 
1.80000 
1.70000 

1.70000 
2.30000 

2.50000 
2.40000 

2. 50000 
2-30000 
2.10000 

1- 50000 
1.90000 
2.10000 
2*10000 
2.40000 

2- 00000 

1.50000 
l.oOrOO 
1.60000 
2 -OOOOO 

2.70000 
2.4000*) 
1.80000 
1.90000 

2.50000 
2.<*KX»n 
2 30000 
2.2*000 
2.  500**0 
2.304>*0 

2 .30u0C 

2.60004* 
2.80000 
2.80000 
2.00000 
2.00000 
1. 7000© 
2. OOOOO 
2-80000 
1.70009 
2.20000 

3. 10000 

3.30000 

2.50000 

2.00000 

1.50000 
2.20000 
2.20000 

2.10000 
l.eoooc 

1.40000 
0.80000 
1.60000 
X. 30000 
V. OOOOO 
2.00000 

1.30000 


RUN  4 

-0.60000 

-0.40000 

-0.40000 

-0.60000 

0.30000 

0.20000 

0.20000 

0.90000 

0.70000 

1.40000 

1.60000 

1.60000 

1.80000 

1.40000 
1. 30000 
1*40000 
1 .60000 
1.60000 
1.70000 
2.20000 
2.20000 

2.40000 
2.60000 
2.10000 
1.50000 
0.70000 
0.50000 
0.30000 
1.20000 
0.40000 
0.90000 
1.90000 
2 .40000 
1.90000 
2.80000 
1.60000 
1.70000 
0.50000 
0.30000 
0.30000 
0.80000 
0.10000 
0.80000 
1.10000 
1.80000 
1.20000 
1.50000 
1.70000 


2.50000 

3.10000 

3.20000 

3.00000 

2.50000 

2.50000 

2. 40000 

2.50000 
2.80000 

2.70000 

3.10000 

3.70000 

4.10000 

4.30000 

4.60000 

4.10000 

4.70000 

4.40000 

4.50000 

4.40000 

4.50000 

3.40000 

3. 30000 

2.40000 
2.80000 
2.40000 

2.30000 

3.10000 
2.30000 
2.40000 
2 .* X*«XX> 

V .60000 

2.40000 

3. 10000 

7.,  oof**  * 

3.10000 

3.60000 

3. 40000 
3.400*W) 

2. . 90000 
-v, . OO  HX. 

3.50000 
2.VOOOO 

3 . 70000 
3.00000 
3.40000 

r.ttoooo 

4 .6**000 

4 . 10000 

4.20000 

3. 20000 

4.40000 
4. 0**000 
2.  90000 

7.40000 
2.60000 
3. 90000 
3.50000 
3 .60006 

4.20000 
4.10000 
3.60000 
5. ROOOO 
4.  totxX* 

3.90000 

3.50000 


RUN  5 

0.60000 
0.10000 
-0.40000 
0.80000 
-0.30000 
-0.30000 
-0.30000 
0.00000 
-0.10000 
0.00000 
0.40000 
0.10000 
0.70000 
0.70000 
1.40000 
1.00000 
1.90000 
2.10000 
2.50000 
Z. lOOOO 
O. 90000 
0.80000 
1.40000 
0.60000 
1.20000 
1.30000 
0.40000 
0.30000 
0.50000 
0.30000 
-0-30000 
-O. 20000 
-0.40000 
-0.20000 
0.70000 
1.00000 
0.00000 
0.30000 
-0.10000 
-0.20000 
0.10000 
-0.10000 
l.OOOOC 
0.40000 
0.80000 
0.90000 
0.30000 
0.70000 


1.30000 

1.30000 

0.70000 

0.30000 

0.60000 

0.30000 

0.00000 

0.30000 

0.80000 

1.60000 

1.60000 

1.70000 

2.70000 
1.90000 
2.00000 
1.80000 

1.50000 
1.80000 

1.30000 
1.60000 
1.60000 
2.20000 
1.80000 
1.20000 
X. 60000 

1. 70000 

1.90000 

2.30000 

2.90000 

2.50000 
2-70000 

3.50000 
4.10000 
3 .60000 

3.30000 
3.30000 

3.40000 

3.70000 
3.  7<x* or* 
3.  50000 
3.80000 
3.7COOC 
3.80000 
4.40OCO 

5.40000 

6.00000 

4.70000 
4.00000 

3.90000 
3.20000 
3.80000 
3.80000 
3.40000 

3. 70000 
3-10000 

2.70000 
1.90000 
2.00000 
2.10000 
2.  VOOOO 
2. 70000 
3.10000 
3.40000 
2.50000 
3.30000 
2.60000 


-0.10000 
-0.50000 
— O.  40000 
0.30000 
0.40000 
-0-20000 
-0.50000 
0.40000 
0.30000 
0.40000 
0.30000 
1.00000 
2.00000 
2.00000 
2.10000 
1.30000 

1.90000 
1.80000 
0.50000 
0.40000 
0.30000 
0.40000 
1.30000 
1.20000 

1.30000 
0.90000 
0. 80000 
0.80000 
0.60000 
1-30000 
1.40000 
2.10000 
1.40000- 
1-70000 
1.80000 
2.10000 
2.20000 
2.00000 

3 . 10000 
2.80000 
3.00000 

7.90000 

2.30000 

3.10000 

3.80000 

3.30000 

2.80000 

3.90000 

4.10000 

4.30000 

4.60000 

3.90000 

2.90000 

3.30000 
3.70000 
4.10000 

4.30000 

4.10000 

3.30000 

3.60000 

3.30000 
3.60000 

2 .30000 

3.10000 
2.30000 
2.30000 


RUN  6 

0.01667 
-0.35000 
-0.45000 
-0.50000 
-0.55000 
-0.31667 
-0.30000 
0.08333 
-0.08333 
0.10000 
0.43333 
0.36667 
0.41667 
0.53333 
0.73333 
0.76667 
O. 95000 
1.30000 
1.53333 
1.40000 
1.53333 
1.31667 
1.41667 
1.10000 
1.06667 
O. 93333 
0.50000 
O.S8S33 
0.91667 
1.06667 
1.03333 
1.36667 
1.55000 
1.53333 
1.80000 
1.41667 
1.20000 
1.50000 
1 . 23333 
1.13333 
1.53333 
1.26667 
1 .33333 
1.63333 
1.81667 
1.88333 
1.78333 
1.90000 
1.53333 
1.58333 
1. 583 33 
1.63333 
1.63333 
1.43333 
1.35000 
1.58333 
1.58333 
1.66667 

1.46667 
1.75000 
2.36333 
2.60000 
2.85000 

2.46667 
2.83333 
2.85000 


2.38333 

2.25000 

2.31667 

2.25000 

2.11667 

2.16667 

1.90000 

2.01667 
2.38333 

2.38333 
2.53333 
2.65000 
2.95000 
2.8^>67 

3. 00000 

2.90000 
3.26667 

3.38333 
3.20000 
3.33333 
3.28333 
3.26667 
3.55000 

3.00000 
3.35000 
3.38333 
3.75000 
3.63333 

4.01667 
3.85000 

3.71667 
3.96667 
4.15000 
3.65000 
3.66667 
5.4*667 
3.71667 
4 . OOOOO 
3.98333 
3.63333 
3.  75000 
3.16667 
3.36667 
3. 13333 
3. 30000 
3.03333 
2.70000 


-20- 
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LOYD  ARC  sec  HP  La««r/GPIB  Data  fit:  ANGULAR 
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LAWRENCE  LIVERMORE  NATIONAL  LABORATORY 

D.  Krulewich 


I know  probably  about  half  of  the  people  here,  so  let  me  introduce  myself.  I used  to  work  in  the  Machine 
Tool  Development  Group  at  Lawrence  Livermore,  which  has  recently  been  renamed  the  Precision 
Systems  and  Manufacturing  Group.  I've  been  in  the  group  for  about  5 years.  We  do  a lot  of  machine 
characterization,  driven  differently  than  in  industry,  since  we're  not  as  concerned  with  high  volume 
production  and  our  precision  requirements  are  higher. 

I have  two  view  graphs  to  show  you.  The  first  view-graph  shows  types  of  projects  that  deal  with  machine 
tool  performance  evaluation.  First,  we  are  involved  with  general  machine  testing,  which  we  do  well. 
When  a new  machine  arrives  at  LLNL,  we  do  a full  characterization  per  B5.54  standard.  Unfortunately, 
we're  probably  not  as  good  at  regularly  maintaining  our  machines  as  we  should  be,  or  as  we  have  been  in 
the  past.  Instead,  if  a machine  is  having  a problem,  the  machinists  in  our  group  would  perform  specific 
tests  for  diagnostic  purposes. 

I am  involved  in  a couple  of  projects,  including  error  compensation.  For  error  compensation  we  are 
concerned  with  characterizing  the  machine  so  that  we  can  remove  the  repeatable  errors  in  the  machine 
controller.  We've  done  error  compensation  in  the  past  using  the  conventional  approach,  which  measures 
all  of  the  separate  21  parametric  errors  for  a 3-axis  machine  tool  and  then  combines  them  to  obtain  the 
tool  point  error  with  respect  to  the  workpiece.  Don  Carter  did  this  on  a DEA  coordinate  measuring 
machine.  We  are  spending  more  effort  to  develop  rapid  methods  of  evaluating  the  machines.  Our  goal  is 
to  map  all  the  machine  errors  in  under  4 hours.  This  is  an  industry-driven  requirement. 

I've  done  a little  bit  of  work  in  thermal  error  compensation.  Thermal  error  compensation  will  relate  the 
machine  errors  to  discrete  temperature  measurements  on  the  machine.  In  real-time,  the  machine  controller 
must  read  these  temperatures,  determine  the  error,  and  then  remove  this  error.  We  have  some  good  ideas 
and  I've  done  a little  bit  of  work  on  the  thermal  growth  of  a spindle  on  a test  stand. 

The  third  area  that  I am  involved  with  could  benefit  a great  deal  from  the  success  of  this  meeting.  The 
goal  of  this  project  is  to  develop  a continuous  spatial-frequency  domain  error  budget.  [The  conventional 
Bob  Donaldson  Error  Budget  breaks  the  errors  into  different  spatial-frequency  bins].  Examples  of  this 
being  form,  waviness,  and  surface  finish.  This  effort  is  driven  by  projects  at  Livermore  that  are  now 
setting  tolerances  on  the  final  part  as  a continuous  power  spectral  density,  such  as  the  optics  industry.  The 
goal  of  this  project  is  to  develop  a continuous  spatial-frequency  domain  error  budget  where  each  machine 
component  error  and  the  errors  due  to  cutting  forces  will  be  presented  in  the  frequency  domain.  This  error 
budget,  similar  to  the  Bob  Donaldson  Error  Budget,  can  be  used  to  set  component  tolerances  during  the 
design  of  a new  machine  tool  to  meet  the  end  performance  specifications.  It  can  also  be  used  to  select  the 
appropriate  machine  tool  for  a part  and  to  provide  information  to  the  part  designer  to  intelligently  set 
tolerances.  For  example,  I have  recently  been  working  on  a BMDO  project  for  the  machining  of  optics 
for  the  space-based  laser.  In  this  project  large  silicon  optics  are  diamond  turned.  There  are  dead  zones 
on  the  optic  where  errors  will  not  affect  the  functional  performance,  so  we  don't  really  care  if  there  is  a 
lobe  pattern  on  the  optic  at  the  dead  zone.  We  can  possibly  use  the  frequency  domain  error  budget  as  a 
design  tool  and  as  an  intelligent  guide  to  setting  the  tolerances. 

The  last  LLNL  project  that  relates  to  the  topic  of  this  meeting  is  the  development  cutting  models.  There 
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are  two  projects  that  our  group  has  recently  been  involved  with.  The  first  was  actually  a summer  student’s 
project  on  the  effect  of  imbalance  on  the  grinding  wheel.  His  goal  was  to  determine  what  the  resulting 
errors  would  be  on  a part  given  an  imbalance  on  the  grinding  wheel,  and  he  considered  the  trade-off 
between  imbalance  and  run-out  on  the  grinding  wheel. 

The  second  was  also  on  the  diamond  turning  of  BMDO  silicon  optics.  We  needed  to  determine  how  to 
set  the  machining  parameters  for  the  silicon  optics  to  optimize  surface  finish,  sub-surface  damage,  and 
tool  wear.  We  have  a silicon  machining  workshop  in  March  where  this  will  be  talked  about  more.  We 
did  a full  parameter  assessment  using  experimental  design  techniques  to  optimize  the  diamond  turning 
process  and  to  determine  which  parameters  were  significant  and  which  ones  weren't.  The  results  were 
very  beneficial  because  high  velocity  and  high  feed  rate  actually  produced  the  best  tool  wear  and  the  best 
sub-surface  damage. 

I think  the  data  base  can  also  address  how  to  store  cutting  models.  We  ended  up  doing  a lot  of  work  that 
could  have  been  avoided  if  previous  results  were  available.  We  began  this  project  with  literature  searches 
before  we  ended  up  doing  this  parameter  assessment  that  helped  us  set  the  ranges  for  our  parameter 
study.  However,  the  literature  did  not  supply  us  with  enough  information. 

I also  wanted  to  make  a side  comment  on  how  to  deal  with  errors  in  the  measurements.  There  may  be 
certain  types  of  errors  such  as  an  outlier  that  your  software  can  find,  but  I think  it  needs  some 
intelligence.  We  still  need  human  involvement  in  all  of  this.  As  an  example,  on  the  diamond  turning 
experiment  that  we  did,  one  of  our  performance  evaluators  was  surface  finish.  The  machinist  gave  me 
the  data.  After  spending  a significant  amount  of  time  studying  the  data,  it  didn't  make  any  sense.  I started 
looking  more  carefully  at  the  data  and  found  that  there  was  an  overlaying  lower  frequency  error  that  we 
were  picking  up  in  our  surface  finish  data  that  was  specific  to  this  machine.  We  think  it  was  caused  by 
the  on-off  of  the  coolant  for  the  spindle.  Since  this  error  was  machine  dependent,  it  wasn't  the 
measurement  that  we  really  wanted.  So  my  point  is  that,  the  real  information  may  be  buried  in  noise  and 
I think  that  there  still  needs  to  be  some  human  intelligence  involved. 

I wrote  down  a couple  issues  that  we've  encountered  that  I think  are  going  to  be  big  issues.  The  first  is 
data  acquisition,  which  came  up  before,  using  the  IQL  software.  Also,  I wanted  to  mention  we  have  tons 
of  data.  If  you  are  interested  in  looking  at  different  forms  of  the  data,  we  have  used  IQL  software,  but 
right  now  we  have  Lab-View  programs  we  run  on  the  Macintosh  with  user-friendly  interfaces  for  all  of 
the  B5.54  tests,  ballbar,  laser  and  levels,  etc. 

Some  important  issues  that  have  not  been  addressed  by  the  B5.54  or  the  axis  of  the  rotation  standards 
include  sampling  rate  and  filtering.  Once  you  start  taking  digital  data,  you're  going  to  have  an  alias  if  you 
don't  filter  samples  at  the  correct  rates.  At  the  last  American  Society  for  Precision  Engineering  (ASPE) 
meeting  I heard  that  the  committee  was  planning  on  rewriting  the  axis  of  rotation  standard  to  include 
frequency  domain  analysis.  I think  that  there  are  a lot  of  important  issues  to  address,  especially  with 
analog  filtering  and  sampling  . We  often  don't  give  these  issues  enough  thought  and  probably  do  it 
wrong. 

The  next  issue,  sign  convention,  is  extremely  confusing.  If  the  measurements  are  just  for  machine 
diagnostics,  the  sign  convention  probably  doesn't  matter  as  much.  But  for  error  compensation,  when 
combining  the  parametric  errors  to  build  the  volumetric  error  model,  the  sign  convention  is  very 
important  and  it's  also  very  confusing.  The  first  time  I was  involved  in  taking  all  this  data  was  on  a 
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CRADA  with  Cincinnati  Milacron.  It  took  us  probably  a month  to  get  the  data,  but  I still  made  the 
machinist  go  back  and  take  more  data  because  the  sign  convention  was  not  clear.  The  biggest  confusion 
arises  when  your  part  is  on  a moving  axis.  The  confusion  stems  from  whether  you're  defining  the  sign 
convention  from  a stationary  point  that  watches  both  the  part  and  the  tool,  or  if  the  coordinate  system  is 
attached  to  the  part  and  watches  the  tool.  Bob  Hocken  does  error  compensation  using  a stationary 
coordinate  system.  He  looks  at  the  positions  of  the  part  and  the  tool  in  a stationary  coordinate  system, 
and  then  subtracts  the  two  to  find  the  error  of  the  tool  point  with  respect  to  work  piece.  Now  the  problem 
is  that  the  measurements  of  the  moving  part  axis  are  opposite  sign  convention  from  what  the  applied 
standard  specifies,  since  the  B5  is  specifying  the  tool  point  with  respect  to  work  piece.  For  the  angular 
errors  it's  just  a sign  difference,  but  for  the  straightness  it's  not  just  a sign  difference  and  requires  a lot  of 
math  to  convert  it  to  the  correct  form. 

Instead,  I have  defined  a coordinate  system  attached  to  the  part,  so  I start  at  the  part  and  I just  loop  all  the 
way  around  to  find  the  position  of  the  tool  in  the  part  coordinate  system.  This  way  all  the  sign 
conventions  are  consistent  with  the  B5  standard  as  tool  point  with  respect  to  the  part.  I have  a strong 
opinion  that  we  need  to  stay  consistent  with  RS-267  so  the  errors  are  consistent  with  the  right-hand 
coordinate  system.  It  is  a little  confusing  what  a right-hand  coordinate  system  is  when  the  part  moves, 
but  I think  we  need  to  stay  consistent . 

When  I was  in  Bob  Hocken's  tutorial  at  ASPE,  he  was  advocating  changing  the  definition  of  straightness 
in  the  standard  because  of  the  sign  convention  problem  that  arises  when  the  part  is  moving  . I think  that 
would  be  a really  bad  idea.  That's  my  opinion.  I,  however,  do  not  think  that’s  a good  idea.  I think  we 
need  to  stay  consistent  with  the  right-hand  coordinate  system. 

Steve  mentioned  a minute  ago  dealing  with  the  non-repeatable  errors.  On  the  spatial-frequency  domain 
error  budget  project,  I am  investigating  how  to  characterize  these  non-repeatable  errors  and  how  to 
determine  the  magnitude  of  the  non-repeatable  component.  One  question  is  whether  the  apparently  non- 
repeatable,  or  apparently  random  errors,  are  attributed  to  temperature  or  something  else.  At  what  level  do 
you  want  to  try  to  explain  them  and  what  level  do  you  want  to  just  say,  "These  are  the  error  bands?".  I've 
been  in  discussions  before  where  people  talked  about  the  error  distribution,  which  must  be  known  to  put 
confidence  intervals  around  these  measurements.  I've  heard  people  say  they're  uniform  distribution,  and 
I've  heard  people  say  it's  bimodal  because  of  hysteresis,  but  I've  never  come  across  anything  that  actually 
did  a full  study  of  the  error  distributions.  That's  one  of  the  things  we  are  investigating  this  summer. 

The  last  concern  deals  with  process-dependent  errors.  All  the  measurements  that  we've  done  have  been 
static  or  point-to-point.  We  have  a big  question  regarding  the  velocity  dependency.  Are  the  errors 
velocity  dependent  or  do  you  reach  some  critical  velocity  and  then  from  that  point  on  they're  no  longer 
velocity  dependent?  This  is  another  issue  that  I'm  interested  in  investigating.  Fixturing  and  load-induced 
errors  are  also  issues  that  I'm  not  sure  how  you  will  handle,  but  are  critical  issues  that  we  are  interested  in 
at  Livermore. 
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Slide  1 


Machine  tool  performance  evaluation  at  LLNL 


♦General  performance  evaluation 

♦ per  ASMEB5.54 

♦ for  machine  characterization 

♦ machine  tools  and  coordinate  measuring  machines 

♦ Error  compensation 

♦ conventional  approach 

♦ rapid  machine  characterization 

♦ HP  and  ICON 

♦ Frequency  domain  error  budget 

♦ LDRD  to  develop  continuous  frequency  domain  error  budget 


Slide  2 

Important  Issues  arising  on  LLNL  projects 


♦ Data  Acquisition 

♦ We  use  LabView  on  Macintosh  for  most  data  acquisition  needs 

♦ Important  issues  include  analog  filtering,  spatial  and  temporal 
sampling  rate 

♦ Sign  Convention 

♦ Sign  convention  is  very  important  for  error  compensation,  not  as 
important  for  machine  characterization. 

♦ Sign  convention  is  very  confusing,  especially  when  the  part  is 
placed  on  moving  axes. 

♦ I prefer  a consistent  right-handed  coordinate  system  of  the  tool 
motion  with  respect  to  the  part. 

♦ Non-repeatable  error  characterization 

♦ What  is  the  typical  error  distribution  (uniform,  bimodal,  etc.)?  Is 
there  a typical  error  distribution? 

♦ How  do  we  place  confidence  intervals  on  our  error  budgets? 

* Cutting  (^[odeh 
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UNIVERSITY  OF  NORTH  CAROLINA  AT  CHARLOTTE 

S.  Patterson 


Most  of  you  saw  the  data  I presented  last  time.  That  still  remains  the  basis  of  the  work  we're  doing,  and  I 
was  just  going  to  take  a couple  of  minutes  and  catch  you  up  on  what’s  new,  or  where  we're  going  at  this 
point,  and  that  occurs  in  two  areas: 

At  the  Center  for  Precision  Metrology  of  the  University  of  North  Carolina  at  Charlotte,  we  have  looked  at 
a variety  of  data  on  the  machine  I presented  last  time,  a regular  3-axis  orthogonal  milling  machine, 
compared  that  data  to  a variety  of  test  cuts  on  a nominally  300  mm  scale  length,  cast  iron  work  piece  and, 
in  general,  come  up  with  agreements  that  are  in  the  neighborhood  of  2 to  5 micrometers  between  the 
machine  modeled  error  and  the  measured  part  error.  Much  of  that  2 to  5 micrometers  is  tied  up  in  the 
metrology  error  on  the  part.  There  is  anyplace  from  1 to  3 micrometers  of  repeatability  issues  and 
accuracy  issues  associated  with  the  coordinate  measuring  machine  used  for  that  measurement  data. 

In  the  process  of  that,  we've  determined  that  there  are  errors  arising  from  flxturing  and  errors  that  are 
arising  from  residual  stress  effects  that  are  on  the  order  of  20  micrometers  in  these  parts.  Considerable 
work  on  the  actual  process  planning  was  necessary  to  get  those  errors  down  in  the  region  where  we  could 
actually  make  a good  correlation  with  the  machine  tool. 

So,  the  first  thing  that  I would  point  out  on  the  virtual  manufacturing  side  of  the  topic  being  addressed  at 
this  meeting  is  that  I don't  believe  that  we  will  be  successful  in  a practical  level  of  virtual  manufacturing 
until  we  have  a protocol  and  a data  interchange,  which  can  accommodate  issues  of  fixturing  and  issues  of 
basic  work  piece  material  conditions.  That,  I believe,  we  have  demonstrated  quite  conclusively,  at  least 
for  this  class  of  parts. 

I would  also  add  the  comment  that  machine-process  interaction  is  probably  on  that  list  as  well,  although 
we  don't  have  the  experimental  data  for  me  to  make  that  statement  quite  as  strongly  as  I can  with  the 
other  two  sources. 

The  limitation  on  the  work  that  we've  done  has  turned  out  not  to  be  the  machine  metrology  data,  or  its 
communication,  since  we're  doing  this  all  in  one  place,  although  that  would  be  a big  issue  if  we  were 
trying  to  work  it  with  one  of  you,  but  actually  the  representation  of  the  work  piece  itself.  This  was 
alluded  to  in  Mr.  Donmez's  earlier  comments,  that  there  were  limitations  working  in  the  Pro-E  format  of 
trying  to  get  the  detail  information  about  the  surface  errors  into  the  work  piece  model. 

In  our  work  we  found  it  necessary  to  develop  a modeling  representation  from  scratch,  basically,  to 
contain  all  of  the  data  that  was  present  in  the  virtual  manufacturing. 

An  interesting  side  note  to  this  is  that  we  are,  in  fact,  able  to  machine  parts  at  about  twice  the  rate  on  the 
machine  that  we  can  on  the  computer. 

There  is  a precedent  for  this,  I might  add,  and  that  is  to  look  at  some  of  the  work  necessary  for  flight 
simulators.  Flight  simulators  were  invented  to  allow  ground  training  of  pilots  originally,  I believe,  with 
some  desire  to  reduce  the  cost  of  pilot  training.  It  turns  out  now  in  most  installations  it  is  more  expensive 
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to  run  the  simulator  than  it  is  to  run  the  airplane.  On  the  other  hand,  I might  point  out  that  I have  to 
bracket  that  comment  because  that's  not  the  case  for  the  scenarios  that  involve  crashing. 

The  same  is  true  of  machine  tools.  There  are  scenarios  that  involve  crashing,  there  are  scenarios  that 
involve  things  that  may  be  considered  abusive  machining.  As  we  heard,  with  higher  machining  rates  and 
very  high  spindle  speeds,  I think  that  we'll  find  a greater  emphasis  on  desire  for  using  virtual  machine 
models  for  very  similar  reasons  that  have  evolved  in  the  flight  training  business. 

I would  also  add,  as  an  update  to  the  last  time,  that  we  have  established  a controllable  machine  enclosure. 
For  lack  of  a better  term,  we  term  it  a "Factory  Simulator,"  which  is  able  to  look  at  the  very  uncontrolled 
conditions  that  exist  in  some  factory  workplace  environments.  This  allows  us  to  take  measurements  of 
machine  parameters  at  different  temperatures  and  at  different  rates  of  change  of  temperatures.  The  result 
is  a set  of  metrology  data  which  reflects  the  behavior  of  the  machine  typically  displaying  its  very 
deterministic  response  to  environmental  variables,  and  this  is  likely  to  get  back  into  the  questions  that 
were  raised  earlier  about  distributions  of  errors  on  machines.  If  we  have  a large  body  of  measurement 
data,  I believe  we're  going  to  be  forced  to  ask  the  question:  what's  the  source  of  the  distribution  and,  as 
Ms.  Krulewich  pointed  out,  what's  the  likely  distribution  of  that?  That  may  well  have  to  do  with  the 
distribution  of  other  variables.  One  of  the  things  that  you  show  fairly  easily  once  you  are  able  to  control 
the  environment  is  that,  if  you  take  a series  of  machine  characterization  runs  over  a variety  of  conditions 
that  reflect  what  you  saw  in  the  workplace,  you  get  an  envelope.  That  envelope,  if  you  choose  then  to 
make  the  statement  that  you  are  sampling  the  environmental  conditions  randomly,  looks  like  a random 
distribution  that  could  be  termed  a repeatability  or  an  apparent  repeatability  error  over  long  times. 

Sorting  this  out  in  terms  of  how  we  actually  use  it  in  virtual  manufacturing  is  one  aspect  that  needs 
considerable  work.  Another  one,  which  is  more  germane  to  this  particular  group,  is  how  we  represent 
that  kind  of  data  because,  in  some  cases,  the  data  will  come  in  without  prior  knowledge  of  the  range  of 
environmental  conditions  and  in  other  cases  it  will  be  very  tightly  coupled.  The  result,  if  there  is  not  a 
distinguishing  feature  in  the  database,  is  going  to  be  substantial  confusion. 

The  other  half  of  the  program  that  we're  involved  with  has  to  do  more  with  the  nature  of  implementing  a 
virtual  manufacturing  requirement.  There,  most  of  the  current  work  has  gone  into  object  modeling  of  the 
machine  tools  and  processes,  and  I would  point  out  that  there  are  two  aspects  that  are  driving  us  right 
now: 

One  of  them  is  a model  for  the  treatment  of  metrology  data  itself.  That  is  to  say,  right  now,  there  are  a 
number  of  ways  that  you  can  measure  machine  tools.  You  can  use  a Renishaw  ballbar,  you  can  use  an 
API  5-D  device,  you  can  use  a Hewlett-Packard  system,  and  all  of  those  systems  tend  to  come  with  their 
own  software  for  data  handling.  So,  at  a level  before  the  metrology  data  repository  kinds  of  questions, 
there  is  also  a question  of  how  can  I treat  with  data  in  a fairly  standard  way.  That,  in  fact,  is  an  object 
model  that  we  are  beginning  to  explore  now. 

The  other  is  the  object  model  of  the  machine  itself.  How  can  I create  a virtual  machine,  or  a piece  of  a 
virtual  machine,  in  a fairly  standardized  plug-in  method  which  is  independent  of  the  program  which  is 
being  used  to,  say,  generate  the  work  piece  representation?  You've  heard  that  addressed  here,  the 
difference  between  the  ADAMS  modeler  and  the  Pro-E  model  for  the  work  piece.  What  we  are  involved 
with  now  is  creating  a C++  based  object  model  where  the  definitions  are  made  at  the  object  call  function 
level  and  the  actual  implementation  inside  the  object  is  completely  free.  If  we  can  gain  some  degree  of 
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commonality  between  other  workers  in  the  field  in  this  regard,  it  will  allow  a lot  of  individual  work  to  be 
done  without  having  to  reinvent  the  entire  structure  of  the  rest  of  the  virtual  manufacturing  requirement.  I 
believe  this  is  something  that  is  going  to  be  quite  vital  in  order  to  actually  make  this  workable  so  there 
can  be  more  players  in  the  field  and  they  don't  have  to  have  their  entire  deep  super-structure  of  program 
modules. 

Finally,  there  is  another  piece  to  the  machine  metrology  business  that  we  really  have  not  much  addressed. 
In  the  data  that  you  saw  this  morning  we  have  examples  of  metrology  data  taken  on  unloaded  machines. 
As  I indicated  last  time,  we  have  one  small  piece  of  data  that  suggests  the  actual  behavior  of  a machine  in 
a systematic  way  may  be  different  for  a loaded  machine  than  it  is  an  unloaded  machine.  We're  in  the 
process  of  developing  a loading  mechanism  that  does  not  influence  the  machine  other  than  constant  load 
to  try  to  be  able  to  tie  that  down.  I hope  to  be  able  to  report  in  about  another  6 months,  or  so,  what  B5 
spindle  drift  tests  taken  with  constant  loads  on  spindles  look  like,  as  compared  to  unloaded  results,  to 
address  some  of  the  apparent  data  anomalies  that  I presented  last  time. 

This  is  only  the  tip  of  the  iceberg  as  relates  to  process  interaction  because,  when  we  get  to  the  stage— we 
get  past  the  stage— that  the  machine  is  moving  all  by  itself,  then  we  get  to  "The  Work  Piece  Strikes  Back," 
and  when  the  work  piece  begins  pushing  back  on  the  tool  you  have  issues  of  chatter  involved,  you  have 
issues  of  dynamic  change,  and  you  have  potentially  changes  in  the  static  geometry  of  especially  large 
machines.  So,  those  are  the  areas  that  we're  moving  into  now  to  try  to  produce  a systematic  modeling 
environment  for  machine  tools. 
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CATERPILLAR,  INC. 
V.  Chandrasekharan 


Some  of  the  things  have  already  been  addressed  and  in  the  previous  meeting,  Nandu  Sirinivasan  gave  an 
overview  of  some  of  our  requirements  and  scope,  so  I won't  repeat  much  of  that.  You  are  also  familiar 
with  some  of  the  work  we're  doing  with  University  of  North  Carolina  at  Charlotte.  We've  been  active  in 
the  virtual  manufacturing  and  machining  area  for  about  2 years  now.  I'll  share  some  of  the  things  that 
we've  gone  through  in  the  last  6 months  and  give  you  an  update,  so  to  speak,  instead  of  going  through 
everything. 

The  simulation  aspect  of  it  is  one  important  arm  of  the  overall  planning.  Simply  put,  we  look  at  it  as  a 
verification  of  the  process  plan.  We're  talking  about  the  performance  of  machine  tools,  and  we  have  to 
take  a step  back  and  go  through  the  definitions  of  performance  the  way  we're  looking  at  it.  Do  we  want 
to  narrow  it  down  purely  on  part  quality?  Do  we  want  to  take  a step  back  and  look  at  some  of  the  other 
things  such  as  cycle  time,  through-put,  and  then  the  up-time  and  efficiency?  Some  of  these  already  come 
into  play  in  the  simulations  that  we  do  today  and  I'll  talk  about  that  next,  where  we  are  today  and  what 
we're  doing  today.  I'd  like  to  go  through  and  address  some  of  these  things  in  the  afternoon  discussions  as 
well,  as  we  go  through  performance. 

The  importance  of  this  work  comes  out  in  the  way  we  end  up  layering  the  database,  the  data  structure, 
and  how  we  store  the  information.  Some  of  the  information  will  be  available  ahead  of  time,  when  you 
buy  the  machine  tool,  some  of  it  has  to  be  added  on  later  when  we  use  it,  and  we'd  like  to  understand 
where  the  group  is  focused  so  we  can  address  the  other  issues.  We'd  like  to  have  one  common  database 
within  the  company  where  one  might  refer  to  the  machine  tool  performance,  the  errors  in  the  machine 
tool  which  may  come  out  of  NIST,  or  any  company  that  finally  maintains  the  database,  and  we'd  like  to 
point  out  that  into  the  rest  of  the  information  that  we  have  to  maintain  within  the  company.  We  have  to 
maintain  subsets  of  this  information  and  we  have  to  understand,  as  Caterpillar,  how  to  maintain  that 
information. 

Currently,  we  have  some  databases  which  we  talked  about  at  the  last  meeting,  information  that's  stored  on 
CD-ROMs  and  on  the  Web;  and  then  we  have  simulations,  tool  tip  simulations  and  kinematic 
simulations.  We  have  a variety  of  Virtual  Numerical  Control  (VNC)  and  we  use  some  of  them.  And  we 
use  soft  machining  on  some  of  these  things.  We  have  a method  of  characterizing  and  reporting  machine 
tool  errors,  the  B5  standard.  What's  interesting  is  we're  going  through  one  of  our  first  few  experiences  of 
actually  trying  to  accept  a machine  with  the  standard  and  we're  finding  a lot  of  things  that  need  to  be 
added  on  and  there  is  a lot  of  discrepancies  in  what  the  machine  tool  builder  is  trying  to  tell  us  and  what 
we're  trying  to  do  with  the  standard.  Those  are  issues  we  want  some  of  these  groups  to  address.  I can  see 
this  that  Hans  Soons  has  written  up,  and  a lot  of  these  issues  that  I'll  be  mentioning  are  covered  in  that. 

How  do  you  address  the  way  in  which  different  hardware  systems  capture  data  that  is  reported?  If  you 
want  to  store  raw  data,  there  has  to  be  a way  of  making  this  all  common,  otherwise  we  get  into  data 
reduction  and  models.  Do  we  agree  on  the  types  of  models  that  are  here  today?  Do  they  capture 
everything  and  are  they  complete?  So  those  will  be  the  issues  that  will  come  up. 

We  went  in  and  looked  at  this  modeling  of  manufacturing  resource  information  that  NIST  put  out— Kevin 
Jurrens,  James  Fowler  and  Mary  Beth  Algeo-and  we  took  the  definitions  of  machine  tools  over  here,  then 
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tried  to  recreate  what's  there  in  Gardener,  and  got  fairly  close.  You  can  capture  most  of  the  physical 
descriptions.  Maybe  that's  a starting  point.  Once  you  can  get  that  and  ensure  the  validity  of  that,  then 
you  get  to  the  next  task  of  assigning  the  performance  of  each  axis,  or  the  performance  of  the  entire 
machine  tool,  because  the  information  that's  out  there  today  is  very  useful  in  buying  a machine  and  trying 
to  narrow  down  the  kinds  of  machines  that  will  fit  your  description  for  manufacturing  a part,  so  let's  not 
leave  that  out. 

The  second  one  is  supporting  existing  simulation  tools.  As  I was  reading  Hans’  write  up  on  the  axes,  he 
has  accelerations,  decelerations  and  things  like  that,  which  were  not  there  in  the  previous  report,  so  I'm 
glad  we're  on  the  right  track.  Where  we'd  like  to  see  this  go  is  to  automate,  or  electronically  create  a 
VNC  model  and  run  it  through.  How  can  we  describe  a machine  tool?  There  are  a lot  of  things  in  here 
on  the  information  required  to  build  a kinematic  model.  Obviously  there  are  things  that  are  not  in  here 
such  as  how  do  you  physically  describe  the  size  of  the  machine  tool.  There  are  trade-offs.  You  can 
automate  portions  of  it,  maybe  80%  of  it;  maybe  you  cannot  get  some  of  the  information  in.  But  that's 
okay;  we  just  need  to  realize  where  it  is  and  feed  off  as  much  as  we  can  so  we  can  at  least  run  things  that 
we  have  today  and  then  figure  out  how  to  get  to  where  we  have  to  in  the  future  with  part  quality. 

With  that,  I'd  like  to  get  into  some  of  the  data  storing  and  layering  issues.  We  had  thought  about  many 
things  as  we  started  looking  at  what  is  out  there  today  and  where  we  can  add  the  error  information  and  the 
machine  tool  characterization  information.  Of  course,  we  don't  have  resources  to  answer  all  these 
questions  internally.  I'm  glad  that  we're  able  to  leverage  NIST.  NIST  has  taken  the  lead  role  in  trying  to 
get  this  accomplished.  It  helps  to  have  a national  standard. 

First  you  need  the  physical  description  of  the  machine,  because  there  is  a lot  of  buying  decisions  made 
that  are  based  on  that. 

Then  what  about  the  machine  tool  errors?  When  you  have  errors,  do  you  associate  them  with  a physical 
entity  or  do  you  have  a separate  pointer  at  the  end  that  just  talks  about  machine  tool  performance  and  then 
go  out  into  this  whole  data  that  deals  with  performance?  Or,  if  you  have  axes  positioning  errors,  should  it 
be  associated  with  that  axis?  If  you  have  repeatability  errors,  should  it  be  associated  with  that  physical 
entity?  In  these  cases,  there  are  some  things  that  are  still  not  clear  where  you  associate  those.  I've  listed 
some  of  those  which  are  fairly  obvious.  Then  you  have,  squareness  error  and  you  have  to  relate  it  to  two 
different  axes.  How  do  you  structure  the  data  to  orient  it  to  a point  from  the  X axis  and  the  Y axis  to  get  a 
squareness  number?  How  does  that  data  get  defined?  Thermal  errors,  for  example,  how  do  you 
characterize  the  effect  of  ambient?  Do  you  want  to  have  expansion  coefficients  on  each  axis,  or  do  we 
want  to  characterize  the  thermal  capability  of  the  machine  as  a whole?  Where  does  that  field  go?  So,  that 
was  an  issue  that  came  up  right  away.  It's  been  about  two  years  that  we've  been  characterizing  machines 
at  Caterpillar  and  trying  to  get  this  information  and  figure  out  how  to  store  the  information. 

The  easy  way  out  seems  to  be  that  you  have  a separate  button  that  says  "Performance  Information,"  and 
then  you  go  into  this  whole  area  where  you're  trying  to  get  this  information  and  keep  that  consistent. 
Maybe  that's  the  right  thing  to  do,  but  we  don't  know  yet. 

There  is  some  information  that  is  available  only  at  the  beginning  when  you  buy  the  machine,  the 
footprint.  If  you  want  to  look  at  the  difference  of  environmental  effects  you  only  get  that  as  you  start 
using  the  machine  and  do  periodic  characterizations.  So  you  have  to  have  fields  to  keep  adding  this 
information  continually. 
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There  are  other  performance  metrics  that  we  can  use  as  immediate  feedback  to  the  designer.  We're 
looking  at  virtual  manufacturing  as  a tool  and  it  was  interesting  some  of  the  issues  that  Mr.  Loyd  Bishop 
from  Boeing  brought  up  saying  that  some  of  the  parts  that  he's  looking  at  require  accuracies  in  ten- 
thousandths  of  an  inch.  We  have  to  decide  where  the  trade-off  is,  where  we  want  to  run  a simulation  as 
opposed  to  where  we  won't,  because  the  time  to  build  a model,  the  time  to  add  all  this  information  and 
run  a simulation  is  fairly  high.  Professor  Patterson  mentioned  that  he  can  cut  a part  a lot  quicker  than  he 
can  run  a simulation.  Building  a model  today  takes  a lot  of  time.  Five  years  down  the  road  we  want  to  be 
a lot  quicker  and  I think  we  will  be.  So,  we  have  to  be  careful  about  where  we  run  simulations.  Today 
the  calls  we  get  from  our  plants  are  where  they're  trying  to  hold  2 and  5 micrometer  straightness  across 
300  mm  in  length,  bores  that  are  maybe  30  mm  in  diameter.  That's  where  some  of  the  problems  are  today 
we  need  to  fix.  It  does  help  running  some  simulations  for  that  because  the  value  added  is  tremendous  and 
it's  worth  the  time  and  the  man  hours  that  you  put  in  running  a simulation  of  that  sort. 

We  have  looked  at  the  data  on  company-specific  business  information.  Machine  tool  is  an  asset  for  the 
company.  Also,  I have  to  figure  out  how  the  asset  is  depreciating,  what's  the  current  value,  and  that's  what 
upper  management  eventually  wants.  If  I have  to  go  in  and  make  a case  for  increasing  capacity  I have  to 
have  information  such  as  burden  rate,  asset  value,  etc.  We  might  have  a cell  of  about  20  machines  that 
are  identical  running  600  parts  and  we  want  to  know  if  you  can  add  more  parts,  if  you  can  get  more 
efficiency  out  of  the  cell,  or  what's  the  quality  and,  if  I get  a new  part,  can  I put  it  into  this  cell  or  not,  and 
again  the  quality  of  the  machines  and  things  like  that  become  an  issue. 

MR.  CALLAGHAN:  Under  company-specific  business  information,  could  we  add  in  there  like  the 
quality  results  of  a particular  machine,  scrap  rate,  because  that  seems  to  be  one  of  the  things  that  seems  to 
get  buried? 

MR.  CHANDRASEKHARAN:  Yes.  In  fact,  that's  the  first  thing  people  want  to  look  at  because  that's  the 
most  tangible  information  for  a foreman.  Their  metrics  are  the  amount  of  scrap  they  make,  scrap  dollars, 
and  that  definitely  is  one  of  the  issues  here.  It's  a lot  easier  to  feed  back  that  information  to  a designer 
today,  or  to  a guy  that's  planning  a process,  than  running  an  extensive  virtual  manufacturing  simulation 
and  telling  him  if  he's  going  to  meet  all  his  quality  metrics. 

Another  issue  with  the  data  storing  is:  what  happens  if  you  want  to  store  actual  data?  Of  course,  the 
problem  is  size  and  then  you  have  the  number  of  runs.  We're  assuming  that  the  positional  errors  are 
independent  of  the  approach  in  some  cases.  Now,  if  it  does  become  a function  of  the  approach  and  you 
start  defining  vectors,  how  many  test  data  do  you  take?  How  do  you  store  all  that  data? 

The  other  issue  is  consistency  across  suppliers.  That  is  definitely  a very  big  issue  for  a company  buying 
the  machine  tools,  and  I think  this  group  and  NIST  is  definitely  the  most  capable  organization  here  to 
address  some  of  these  issues. 

The  way  the  data  is  stored  and  processed  is  very  unique  and  I think  that  came  up  in  some  of  Loyd's 
presentation;  such  as  how  IQL  stores  it,  and  how  he  manipulates  the  data.  Even  when  you  present  raw 
data  it's  still  manipulated  raw  data,  it's  never  completely  raw  data,  so  that  becomes  an  issue  as  well. 

There  are  issues  about  the  different  types  of  data.  You  get  into  the  issues  of  not  just  floating  points  and 
numbers,  integers,  but  the  sampling.  How  do  you  sample  them,  how  many  fields  do  you  allocate?  I think 
we've  already  started  addressing  those  and  I wanted  to  bring  that  out  and  I think  will  come  out  in  the 
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discussions  again. 

We  looked  at  model  coefficients.  There  is  the  issue  of  how  complete  is  a model  coefficient?  How 
complete  are  the  models  we  are  addressing  today?  Have  we  independently  assessed  the  errors,  for 
instance  repeatability?  If  you  take  repetitions  on  the  same  measurement,  is  the  variation  a function  of 
temperature?  Is  that  the  true  repeatability  of  the  machine?  We  were  doing  the  tool  change  repeatability 
on  our  machine  acceptance.  Of  course,  if  you  change  the  tool  you've  got  to  move  to  a certain  point  and 
measure  in  the  cap  nest.  There  are  positional  repeatability  errors  that  are  associated  with  the  tool  change 
repeatability.  As  we  were  going  through  the  machine  acceptance,  we  were  not  sure  how  to  actually  sort 
those  out  accurately  enough.  There  has  to  be  some  standard  ways  of  sorting  some  of  these  issues  out. 

As  research  progresses  in  academia  and  in  other  places  you'll  always  have  more  and  different  types  of 
machine  models  involved.  Do  you  want  to  restrict  yourself  to  the  type  of  models  that  we  have  today? 
Again,  it  goes  back  to  the  issue  of  how  complete  they  are. 

Another  interesting  thing  that  we  found  is  the  issue  of  scrap.  Eventually  the  goal  is  to  figure  out  how 
good  is  the  part  that  you're  going  to  machine.  The  B5  standard  has  a test  block  that  you  can  go  in  and 
machine  today  and  collect  that  data.  But  can  we  store  that  information  some  way?  We  haven't  really 
addressed  that  issue  yet.  But  taking  that  test  block  and  inspection  data  from  that,  can  we  maybe 
characterize  the  repeatability  of  the  machine?  How  do  you  standardize  the  tooling?  How  do  you  get  the 
supplier  to  maintain  that?  When  we  buy  a machine,  let's  say  with  a high-speed  spindle  or  a high  axis 
travel  rate,  we  don't  care  if  the  accuracy  of  the  machined  test  block  is  extremely  good  when  it  was  cut 
with  cutting  parameters  outside  the  range  that  we  want  to  use  the  machine  for.  If  it's  running  at  slow 
spindle  speeds  and  real  axis  travel  rates,  it  may  be  a very  accurate  machine  but  it  doesn't  mean  much.  We 
want  the  test  block  to  be  machined  at  typical  feeds,  speeds  and  typical  tooling  that  the  machine  will  be 
used  for. 

The  issue  of  chatter  limits  and  stability  data  came  up  and  I've  already  had  some  discussions  here  on  how 
we  can  try  and  store  that  in  the  database.  One  issue  that  we're  trying  to  do  some  research  on  at  Caterpillar 
is  assessing  the  joint  stiffness  and  damping  up  to  the  spindle  taper.  Then,  we  add  tooling  information  and 
determine  the  transfer  function  of  the  tool  and  then  compute  stability  lobes  and  chatter  limits  based  on 
that. 

Finally,  we  have  to  address  the  database  design,  the  structure,  and  the  storage  issues.  We  have  to  address 
the  completeness  of  the  models,  completeness  of  the  data,  the  way  the  data  is  parsed  and  sorted.  Then 
show  consistency,  across  suppliers,  write  down  procedures,  data  collection  methods,  and  how  they  report 
this  information.  Of  course,  we  want  to  promote  supplier  acceptance  and  we'd  like  to  see  more  machine 
tool  builders  here. 

I think  we  want  to  not  limit  the  scope  of  the  data  definitions  to  just  simulation  alone.  Virtual 
manufacturing  is  definitely  where  we  want  to  get  to  and  we're  working  hard  to  get  to  that.  We're  already 
addressing  some  of  the  other  issues  of  how  you  basically  buy  a machine  by  its  work  volume  definitions  as 
the  starting  point,  and  then  go  into  the  performance  deeper  later  on. 

We  definitely  are  looking  for  more  correlation  of  machine  errors  and  the  characterization  to  part  errors. 
We've  been  involved  in  a lot  of  other  issues  such  as  modeling,  fixture  and  process.  We  started  modeling 
the  process,  the  loads,  the  deflections,  and  fixture  distortions  because,  in  a lot  of  our  cases,  the  fixture 
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distortion  is  enormous  and  we  get  up  to  120  to  150  micrometers  of  errors  from  fixture  distortion.  We 
want  to,  however,  leave  it  out  of  the  scope  of  what  we're  doing  here  and  keep  the  scope  restricted  to 
machine  tools,  machine  tool  errors,  and  how  that  translates  to  part  errors.  Some  of  it  might  be  a selfish 
interest  because  we  are  already  working  on  the  other  issues  and  we're  trying  to  plan  on  how  to  bring  those 
in.  The  other  reason  is  that  the  scope  of  the  problem  becomes  enormous  and,  given  the  resources  that  we 
have,  we  think  the  focus  will  help  us  a lot  more  in  organizing  what  we  have  today.  We  can  definitely  do 
a lot  better  with  the  data  we're  collecting  today  on  machine  tool  characterization  and  storing  that 
accurately. 

In  terms  of  the  simulation  tools,  there  are  no  CAD  vendors  here.  That  was  another  issue  that  we  talked 
about  from  the  previous  meeting  after  we  got  back  and  tried  to  work  out  our  strategy.  We  don't  do  too 
much  research  in  the  area  of  CAD  at  Caterpillar;  we  leave  that  to  the  vendor.  When  we  start  looking  at 
different  companies  using  different  CAD  systems,  issues  of  part  representation  become  more  important. 
We  definitely  would  like  a graphic  representation  of  the  part  down  the  road.  But  I think,  as  a starting 
point,  we'd  like  to  assume  that  the  people  that  are  calling  out  the  specs  on  the  part  are  doing  something 
within  reason  by  understanding  the  functionality  of  the  part.  We’d  like  to  go  back  and  compute  those 
geometric  dimensioning  and  tolerance  specifications,  match  the  calculated  ones  against  the  specifications 
as  a first  step  and  show  that  in  some  kind  of  a graphical  form,  as  opposed  to  creating  the  entire 
representation  of  the  part.  That  gets  into  a level  of  detail  that  we  certainly  don't  understand  and  I think  it 
would  be  more  profitable  if  we'd  try  to  focus  on  the  areas  of  the  machine  tools  and  the  characterizations 
and  things  like  that. 
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AUTOMATED  PRECISION,  INC. 
Q.  Ma 


API  is  a manufacturer  of  measuring  instruments.  We  also  are  involved  in  a lot  of  machine 
measurements.  The  main  reason  for  us  trying  to  promote  this  new  technology  is  the  fact  that  just  recently 
machine  measurements  have  been  accepted  as  a national  standard. 

Today,  I would  like  to  use  the  data  from  one  machine  we  measured  showing  the  types  of  measurements 
people  usually  want.  Basically,  the  measurements  people  request  are  the  ones  described  in  ANSI/ASME 
B5.54  standard.  Normally,  they  want  to  have  a linear,  straightness  and  angular  error  tests  for  each  axis 
along  with  a periodical  test,  a bidirectional  repeatability  test,  and  the  body  diagonal  displacement  tests. 
The  other  tests  people  want  are  contouring  performance  in  three  different  planes  as  well  as  squareness  of 
axes.  People  are  also  interested  in  the  spindle  thermal  growth.  To  complete  a task,  sometimes  we 
measure  the  roll  of  the  machine  slides  [Slide  1]. 

We  use  the  5-D  laser  system  to  measure  5 different  types  of  errors  at  the  same  time  [Slide  2].  For 
example,  while  measuring  X axis  linear  displacement  error,  we  also  measure  straightness  in  the  vertical 
and  horizontal  planes  as  well  as  pitch  and  yaw  errors  simultaneously.  This  way  we  can  reduce  the 
measuring  time  by  roughly  about  80  percent.  One  can  measure  a 3-axis  machine  within  3-4  hours. 

The  other  instrument  we  commonly  use  is  the  ballbar  [Slide  3].  The  third  one  is  the  spindle  thermal 
measurement  system,  which  is  either  capacitance  or  inductance  based  proximity  measurement  system 
measuring  linear  thermal  growth  of  the  spindle  along  three  orthogonal  axes  as  well  as  the  tilt  drift  in  two 
planes  [Slide  4].  During  these  measurements  we  put  thermal  sensors  on  critical  positions,  like  near  the 
spindle  bearings,  and  roughly  see  the  correlation  between  the  temperatures  and  the  spindle  drift. 

When  we  are  measuring  a machine,  involving  many  types  of  errors,  we  create  a bunch  of  files  that  can 
prove  really  frustrating  for  the  user.  To  handle  these  files  we  are  developing  software  which  is  Microsoft 
Access-based.  We  call  it  the  WINNER  Data  Management  System.  Basically,  this  software  will  group  all 
the  measurements  together.  We  are  also  trying  to  set  up  a kind  of  a format  for  the  file  name  [Slide  5]. 

For  a filename  in  the  MS-DOS  work  you  can  only  have  8 characters.  We  use  the  first  three  as  the 
machine's  ID.  The  fourth  character  is  the  test  type,  and  you  assign  each  number  based  on  what  type  of 
test  you  are  doing.  The  fifth  will  be  the  axis  being  measured  for  different  tests.  The  last  three  characters 
are  used  for  test  numbers.  For  example,  5131A001  indicates  the  machine  ID  as  "513,"  and  the  "1" 
indicates  it  is  a 5-D  measurement.  "A"  is  axis  X,  and  "001"  is  the  first  of  files.  In  this  way  we  can  clearly 
identify  what  tests  they  have  done  and  then,  later,  when  they  put  it  into  the  program,  the  program  will 
recognize  it  and  put  that  file  into  the  right  space. 

We  also  code  error  file  format  [Slide  6].  This  one  basically  summarizes  the  measurement.  Instead  of  100 
raw  data,  we  just  track  all  the  key  components  from  the  data  and  then  put  it  into  a file.  This  file  will  be 
read  by  the  database  system.  For  example,  for  the  linear  measurement,  we  save  the  maximum  error, 
maximum  reverse  error,  then  the  increment  for  the  measurement,  the  total  travel,  also  the  air 
temperature,  the  material  temperature,  and  the  starting  position. 
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The  primary  layout  of  our  system  is  shown  in  Slide  7.  We  have  the  main  part  where  you  can  type  into 
machine  information.  On  the  other  side  you  can  go  into  the  real  evaluation  graphs  and  eventually  print 
out  a report. 

Next  I will  just  roughly  show  what  the  data  looks  like.  This  is  the  linear  measurement  of  axes  [Slide  8] 
and,  in  the  meantime,  we  also  record  the  straightness  measurement  and  the  angle  [Slides  9 and  10].  All 
five  of  these  measurements  were  done  simultaneously.  Then,  we  fit  the  data  into  this  management 
software  and  create  a report.  And,  if  the  people  follow  the  instructions,  they  can  see  how  the  last  column 
will  automatically  create  this  report  [Slide  11]. 

This  is  the  diagonal  measurement  [Slide  12].  Normally,  we  provide  a diagram  [Slide  13]  as  well  as  the 
summary  information  [Slide  14]  showing  machine  body  diagonals  with  repeat  to  machine  axes. 

A diagram  of  the  repeatability  measurement  and  a summary  of  the  report  are  shown  in  Slides  15  and  16 
respectively. 

Periodical  measurement  is  similar  to  the  linear  measurement.  The  results  are  shown  in  Slides  17  and  18. 

Ballbar  measurement  data  are  shown  in  Slides  19,  20,  and  21.  We  only  identify  backlash,  servo  error, 
periodic  error,  scale  mismatch,  and  squareness  using  the  ballbar  because  we  feel  that  straightness  is 
insignificant  using  the  ballbar. 

We  created  a measurement  system  for  the  spindle  thermal  growth  measurements.  Right  now,  not  many 
people  are  really  interested  in  the  modeling,  but  they  want  to  know  how  large  the  thermal  growth  is  [Slide 
22].  Measurement  data  and  summary  are  shown  in  Slides  23  and  24  respectively. 

The  last  one  is  using  the  tilt  sensor  to  measure  roll.  The  set  up  sketch,  data  and  summary  are  shown  in 
Slides  25,  26,  and  27. 

Another  thing  we're  trying  to  do  is  build  up  the  model  based  on  all  the  measurements  so  that  the 
algorithms  will  probably  be  based  on  the  model  that  has  been  developed  at  NIST  and  other  institutes. 
Then  our  major  challenge  is  how  to  fit  the  data  into  the  model  for  different  type  of  machines  and  for 
different  set-ups.  The  sign  will  make  a big  difference.  So  we'll  work  on  that. 

And  my  final  comment  is,  based  on  our  experience  with  the  industry,  the  user  is  relying  on  the  instrument 
itself  to  give  them  all  these  answers,  like  repeatability  and  uncertainties.  The  management  doesn't  want 
to  have  any  guessing;  they  just  want  this  to  be  automatic  and  as  simple  as  possible. 
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INDEPENDENT  QUALITY  LABORATORIES 
R.  Callaghan 


The  group  of  people  that  spoke  here  the  last  session  were  primarily  commercial  people  involved  in  the 
area.  I thought  I would  give  you  an  idea  of  where  I thought  the  technology  was  right  now  from  a 
commercial  standpoint,  such  as  what's  available  and  what  needs  development  and  so  forth,  because  we 
have  quite  a variety  of  interests  in  this  group. 

I've  got  a key  here.  "A"  means  it's  available  commercially,  ”B"  means  it  requires  some  development,  and 
"R"  means  it  requires  further  research  before  we  can  begin  to  introduce  this  into  the  market.  I will  try  to 
address  some  of  the  issues  that  I think  are  important  when  we  get  involved  with  this  kind  of  measurement 
and  this  kind  of  data. 

The  first  thing  is  repeatable  measurements.  That  is,  being  able  to  describe  how  we  set  up  the 
instrumentation.  Secondly,  providing  it  in  text  format,  Loyd  was  showing  you  how  he  does  it  with  his 
system.  We  also  have  some  capability  for  doing  digital  imaging.  There  is  a lot  of  software  right  now 
that's  available  with  digital  images  or  digital  photographs.  One  issue  that  came  up  recently  was  video  and 
sound.  We  work  on  the  ground  with  the  maintenance  mechanics  and  these  are  some  of  the  things  that 
they've  been  asking  for.  They  want  more  direction  for  the  guys  who  are  going  to  be  capturing  this  data. 

If  you  ask  somebody  to  capture  this  data,  and  if  you  are  not  explicit,  you'll  probably  spend  as  much  time 
trying  to  figure  out  what  they've  done  as  it  would  take  you  to  go  out  there  and  do  it  yourself.  So,  these 
particular  aspects  are  very  important  underlying  issues  relative  to  getting  data  that's  going  to  be  of  value 
at  all  if  we  want  to  go  forward  with  any  of  the  other  activities  that  we  were  talking  about  this  morning. 

Certainly,  if  we  look  at  the  choices  of  instrumentation,  a lot  of  this  instrumentation  has  been  around  for 
quite  some  time,  although  it  hasn't  had  much  acceptance  in  industry.  There  are  a few  opportunities  here 
for  further  development  and  research  in  some  products,  but  everything  that  we  really  need  to  make  the 
measurements  is  available  currently. 

You  heard  Quan  Ma  mention  what  he  perceives  from  his  customers'  standpoint,  and  that  is  the  need  to 
gather  this  data  as  automatically  and  as  rapidly  as  possible.  I think  there  are  a number  of  software 
packages  out  there  from  a variety  of  manufacturers  that  can  automatically  gather  this  data.  We  have  one 
issue,  the  sign  conventions,  that  we  need  to  develop.  For  me,  right  now,  this  is  one  of  the  most  important 
issues  that  this  group  could  deal  with  immediately.  In  fact,  I called  Jim  Bryan  on  Friday  to  talk  about 
this,  to  ask  him  what  he  did  about  sign  conventions,  and  he  says,  "You  know,  I've  been  doing  this  for  50 
years  and  I'm  still  confused.  I still  tell  people  to  use  the  right-hand  rule,  but  you've  got  to  point  your 
thumb  north,  or  you've  got  to  point  it  up,  or  point  it  east  for  a particular  machine."  He  says,  "I  don't  have 
anything  solid  yet  in  that  area." 

When  we  do  these  measurements  out  in  the  field  one  of  our  major  costs  right  now  are  the  machine  tool 
part  programs  to  exercise  the  machines.  We've  had  innumerable  cases  where  large  quantities  of  time 
have  been  consumed  on  the  shop  floor  in  trying  to  get  the  machines  to  move  so  that  we  could  take  the 
data  automatically.  In  fact,  I did  a demo  at  Boeing  a few  years  ago  and  we  stood  for  two  hours  in  front  of 
a machine  with  28  people  trying  to  make  it  go  around  in  a circle  and  we  finally  abandoned  that 
demonstration  because  we  couldn't  get  it  to  do  that.  So  that's  another  important  issue.  It  probably  doesn't 
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require  as  much  research  as  it  does  development,  but  I think  a repository  of  machine  tool  part  programs 
for  making  these  measurements  is  a good  idea.  One  other  thing  I wanted  to  mention  is  that  there  is  a 
machine  tool  out  there  right  now  that  has  a hazard  in  it  when  we  run  these  test  programs.  If  you  use  a 
standard  command,  which  is  an  MOO,  to  stop  this  particular  machine,  it  will  orient  the  spindle.  So,  if  you 
have  a piece  of  instrumentation  in  that  machine,  you  may  get  hurt  by  it.  I've  talked  with  their  safety  chief 
about  this  issue.  It  isn't  such  a problem  when  you're  making  parts.  But  when  you  have  the 
instrumentation  and  use  a standard  part  program,  you're  going  to  get  some  excitement. 

I would  recommend  that,  in  the  course  of  the  next  day,  we  look  closely  at  the  standard  for  axis  and 
motion  nomenclature  for  NC  machine  tools  and  see  if  it  has  value.  I'm  going  to  start  to  use  it,  because  I 
just  discovered  it.  It  shows  the  right-hand  rule  for  doing  the  sign  conventions.  In  fact,  this  is  out  of  the 
older  standard;  the  newer  one  has  quite  a few  more  illustrations  of  machines,  which  I think  is  super. 

They  have  some  of  the  filament  winding  machines,  as  well  as  the  standard  machine  tools  in  it.  This 
standard  does  relate  to  the  part  and  not  to  the  machine  motions. 

If  we  look  at  the  methods  of  storage  and  retrieval,  there  are  a lot  of  systems  out  right  now  that  have 
proprietary  data  files  and  you  can't  get  into  them.  Most  of  the  systems  now  have  ASCII  data  files  and 
from  the  commercial  side,  I think  what  we  need  to  be  moving  to  is  certainly  the  database  standard  format. 

We've  been  working  on  national  and  international  standards  committees.  These  standards  describe  the 
methods  for  analysis  of  some  of  the  data  collected  on  machine  tools  for  comparison  and  acceptance 
purposes.  On  the  other  hand,  the  maintenance  managers  are  asking  us  more  and  more  for  information  so 
that  we  can  automatically  guide  the  maintenance  mechanics  in  repairing  the  machines.  They're  not  as 
interested  in  simulations  at  the  moment,  but  they  just  want  some  nice,  simple  form  of  the  data  so  we  can 
say,  "Okay,  here  is  where  you  have  to  straighten  the  machine,  here's  where  you've  got  to  correct  the  servo 
gain  error.”  There  are  a number  of  software  packages  now  that  are  going  along  with  the  ballbar  systems 
that  seem  to  be  effective.  Shop  floor  maintenance  mechanics  like  that  type  of  thing.  But  I think  there  is 
an  awful  lot  more  opportunity  in  this  area  for  the  short-term  gain  and  I think  we  haven't  discussed  that  at 
all  yet.  From  a commercial  standpoint,  the  simulations  to  benefit  the  maintenance  mechanics  will  have  a 
lot  more  bang  for  the  buck  than  the  factory  simulation. 

I view  the  methods  of  applying  this  technology  in  several  ways.  Buying  and  selling  is  one  of  them. 
Companies  are  wrestling  with  their  suppliers  over  the  application  of  the  standards.  Maintenance  support 
is  the  other  application  area.  If  we  take  a look  at  a typical  machine  in  the  shop  and  the  way  they're  being 
applied,  I usually  tell  our  customers  that  we  can  take  and  improve  the  volumetric  performance  of  a 
machine  by  a factor  of  2 without  much  difficulty  at  all.  It's  simply  because  people  in  the  past  have  not 
had  enough  information  about  what  this  machine  can  do.  You  can  see  from  the  earlier  discussions  we 
had  today  about  the  repeatability  of  these  machines— they're  incredible— and  the  problem  with  the 
machines  has  been  that  they  have  not  been  set  up  correctly.  If  we  had  some  way  of  visually  presenting 
the  error  conditions,  or  simulating  the  error  conditions  in  the  machines,  we  could  explain  the  maintenance 
mechanics  and  their  supervisors  what  the  real  problems  are  and  how  to  correct  them  easily. 

If  we  go  a little  further,  we  have  the  issues  of  the  error  compensation.  Lead  screw  error  compensation 
has  been  around  for  a long  time,  although  it's  misused  quite  frequently.  3D  volumetric  compensation  is 
available,  I think,  from  all  the  (Coordinate  Measuring  Machine)  CMM  manufacturers  right  now.  There 
are  a few  people  that  have  3D  volumetric  corrections  for  machine  tools,  although  I think  it  requires  a lot 
more  development  and  research.  We  have  thermal  error  compensations  available. 
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The  machine  simulations  and  factory  simulations  are  areas  that  we  need  to  do  a lot  more  research.  I put 
“D”  in  the  machine  simulations  because  I think  that's  an  important  point  right  now  to  get  people  looking 
at  this  data  in  a little  bit  different  form  than  they  have  in  the  past. 

There  was  one  other  issue  that  I didn't  put  here.  That  was  the  frequency  content  of  data.  We  need  to  do 
something  in  studying  that  because  I'm  finding  that  there  is  an  awful  lot  of  variation  in  the  data  that 
comes  from  the  test  procedure  itself,  particularly  depending  on  how  you  filter  the  data,  and  a lot  of  the 
commercial  products  have  filtering  built  in.  You  wouldn't  even  know  what  it  is.  We  have  it  with  the 
electronic  levels,  we  have  laser  interferometers,  and  all  those  devices  have  built-in  filtering.  We  need  to 
come  up  with  methods  of  filtering  the  noise  out  of  the  data  and  yet  keep  the  basic  information  about  the 
real  machine  errors. 

MR.  BISHOP:  I saw  on  TV  an  advertisement  that  Casio  has  digitized  pictures.  You  can  look  in  the  back 
of  the  camera  and  actually  see  what  you're  going  to  either  save,  or  erase.  Do  you  have  this  kind  of 
capability  with  your  software,  because  I think  that  is  really  a nice  feature,  where  you  can  go  out  and  take 
a picture  of  your  set-up  and  include  that  right  in  on  the  computer  screen. 

MR.  CALLAGHAN:  Actually  not.  But  if  anybody  is  interested,  we  can  talk  about  it  off-line. 

MR.  BISHOP:  Well,  I thought  that  was  really  important  for  the  documentation  and  the  repeatability  of 
the  tests.  I don't  have  a problem  because  I'm  the  same  guy  that  does  the  tests  over  and  over,  so  I can 
document  it  and  I can  pretty  much  go  back  and  test  it  over  time.  If  I test  something  and  I tell  maintenance 
mechanics  they  need  to  repair  it,  then  it  would  be  really  good  if  I had  a digitized  picture  on  the  computer 
screen  so  he  could  duplicate  the  test,  duplicate  the  error,  and  correct  the  problem. 

MR.  CALLAGHAN:  I think  this  is  something  else  that  should  go  along  with  that  repository  of 
information.  If  you're  a scientist  or  an  engineer  who  is  studying  a particular  data  set  and  you  don't  have 
access  to  this  thing  you're  wasting  your  time.  You  have  to  know,  for  example,  at  what  plane  a laser  shot 
was  taken.  You  also  have  to  know  the  direction  and  where  the  temperature  probes  are.  One  way  to  get 
that  in  the  database  is  with  the  actual  digital  images. 
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NIST  PRESENTATIONS 


MACHINE  TOOL  METROLOGY  INFORMATION  MODELING 

S.  Frechette 


I would  like  to  spend  a few  minutes  discussing  information  modeling  and  how  we  intend  to  use  it  in  this 
project.  Why  use  information  modeling?  Because  it  provides  a basis  for  common  understanding  and 
communications  among  domain  experts  and  application  developers.  In  order  to  develop  software 
applications  that  are  capable  of  exchanging  data,  we  must  devise  a mechanism  to  express  knowledge 
from  domain  experts  in  a form  that  application  developers  can  understand. 

The  goal,  therefore,  is  to  share  data.  We  need  to  define  the  data  requirements  for  our  systems.  In 
addition,  we  need  to  enable  the  development  of  systems  — software  systems  in  this  case  — to  exchange 
information.  For  example,  company  A has  just  completed  a ball  bar  test  and  wants  to  transfer  that  data  to 
company  B who  will  analyze  it.  To  accomplish  this,  the  receiver  must  be  able  to  understand  the  format 
the  sender  is  using.  At  this  point,  questions  arise:  "How  can  I take  your  data?  What  format  is  it  in? 

What  system  are  you  using?"  The  goal  is  to  have  the  information  flow  seamlessly  either  from  system  to 
system  or  from  system  to  database  to  system. 

Slide  5 shows  a typical  modeling  process.  In  practice,  the  modeling  process  is  not  linear  but  iterative  in 
nature.  One  must  know  something  about  an  application  before  one  develops  a scope,  but  when  viewed  as 
a linear  process,  we  develop  a scope,  an  activity  model,  as  well  as  define  our  activities  and  identify  what 
data  is  flowing  between  them.  An  information  model  will  further  define  the  data.  And,  if  done  correctly, 
may  be  processed  into  a computer-interpretable  form  such  as  EXPRESS.  This  is  a form  that  an 
application  developer  can  understand  and  it  is  possible  to  generate  database  calls  and  schema  directly 
from  an  EXPRESS  representation. 

Application  development  is  an  iterative  process  with  several  activities  occurring  in  parallel.  At  this  point, 
we  are  in  the  activity  modeling  phase  as  shown  in  slide  6.  Yet  we  will  probably  have  to  revisit  the  scope 
because  I do  not  think  we  have  defined  it  well  enough.  It  is  also  not  yet  clear  what  applications  we  are 
targeting.  The  target  applications  have  significant  impact  on  the  scope  and  data  model  development. 

In  terms  of  the  scope,  we  need  to  understand  the  process.  There  have  been  several  viewpoints  expressed 
here  today.  Are  we  looking  at  machine  tools  in  terms  of  purchasing?  Analysis?  Maintenance?  These  are 
all  valid  but  different  viewpoints  which  may  have  different  data  requirements.  What  information  do  I 
need  to  know  about  a machine  tool  to  purchase  one  effectively?  Why  is  this  machine  not  functioning 
correctly?  I need  to  fix  it.  What  information  do  I need?  I need  to  understand  the  application  and 
understand  the  process.  We  need  to  establish  a reference  architecture,  so  people  from  different  industries 
and  different  viewpoints  can  discuss  the  information  requirements. 

Slide  7 shows  an  activity  model.  Essentially,  an  activity  and  information  flowing  in  and  out  of  that 
activity.  This  example  shows  two  activities  (boxes)  with  information  flowing  from  one  to  the  other  (from 
Activity  1 into  Activity  2).  The  data  flowing  between  the  activities  is  what  we  are  really  trying  to 
capture.  One  way  to  accomplish  this  is  to  define  all  of  our  activities  and  identify  all  the  data  flowing  into 
and  out  of  each  activity. 
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Slide  8 shows  an  example  of  an  activity  model  operating  conditions  for  a process  are  being  measured. 
Environment  data  is  flowing  into  the  first  activity.  Temperature  data  is  flowing  between  the  monitor 
activity  and  controller  activity.  Perhaps,  if  the  temperature  is  too  high,  the  controller  will  put  out  a danger 
signal.  This  information  may  be  used  in  some  other  activity,  for  example,  to  start  a cooler  or  shut  down  a 
machine. 

We  can  see  inn  slide  9 how  involved  an  actual  model  becomes  when  a number  of  activities  are  defined. 
Each  activity  (box)  on  this  page  will  devolve  into  a separate  diagram.  This  refinement  continues  until  the 
desired  level  of  detail  is  achieved. 

The  activity  model  is  only  a tool  to  help  identify  the  data  requirements.  Essentially  we  are  left  with  lists 
of  data  elements.  Now  we  must  organize  these  lists  and  arrive  at  a common  understanding  of  the 
terminology.  For  example,  if  I ask  person  A to  make  me  a list  of  all  the  data  he  needs  to  understand  a 
machine  tool,  and  then  I ask  person  B to  do  the  same  thing,  the  chances  that  I will  receive  incompatible 
results  are  high.  Person  A recorded  his  data  in  one  column  and  used  capital  letters.  Person  B used  all 
lower-case  letters  and  recorded  his  data  in  rows  using  commas  as  delimiters.  I will  not  be  able  to 
compare  the  lists. 

With  the  list  of  data  elements  established,  we  will  use  a standard  format,  such  as  EXPRESS  to  unify  our 
approach  to  organizing  the  data  as  shown  in  slide  10.  We  will  identify  data  entities,  assign  attributes  to 
those  entities,  determine  data  types,  and  most  importantly,  we  will  establish  concise  definitions  for  all 
terms  in  the  model.  This  will  allow  us  to  share  the  model  with  other  people. 

Slide  1 1 shows  a list  of  several  modeling  languages.  IDEF  10  is  a language  used  for  activity  modeling. 
Other  modeling  languages  are  available.  EXPRESS  will  be  used  for  this  project. 

Slide  12  provides  a brief  overview  of  EXPRESS  syntax.  The  schema  is  a domain,  a collection  of 
EXPRESS  statements,  which  describe  information.  An  EXPRESS  model  is  made  up  of  entities.  These 
entities  have  attributes,  and  those  attributes  have  types.  Attributes  can  be  inherited  from  other  entities 
There  are  also  rules  and  functions— such  as  supertypes  and  subtypes.  I will  not  go  into  any  more  detail.  I 
am  sure  most  everyone  on  the  room  is  familiar  with  computer  languages  and  should  have  no  trouble  with 
the  EXPRESS  overview  in  the  handout. 

Slide  13  shows  a diagram  from  the  RRM  tooling  database.  Tool  assembly  is  an  entity;  it  has  an  attribute 
"magazine  slot  number."  That  attribute  is  type  "Integer."  At  some  point,  tool  assembly  was  identified  as 
an  important  piece  of  data.  One  of  its  attributes  is  slot  number  which  should  be  an  integer  Similarly,  one 
can  follow  the  rest  of  the  attributes.  Every  line  coming  out  of  "Tool  Assembly"  is  an  attribute.  It  has  a 
name  and  it  has  a type.  The  dotted  lines  mean  it  is  a defined  type.  The  "ABS"  means  it  is  an  abstract 
entity.  For  comparison,  the  textual  version  of  EXPRESS  is  on  the  left-hand  side.  EXPRESS  is  text. 
EXPRESS  G is  the  graphical  representation. 

Slide  14  shows  the  list  of  machine  tool  data  which  was  used  to  create, the  machine  tool  metrology  model. 
The  list  represents  data  elements  important  to  machine  tool  metrology.  Once  these  elements  are 
identified,  data  types  must  be  determined  and  relationships  between  elements  must  be  established.  If  this 
is  done  using  a known  format,  such  as  EXPRESS,  it  may  then  be  processed  directly  into  function  calls  for 
our  database  [e.g.,  SQL  (Standard  Query  Language)  calls].  This  will  be  the  basis  for  the  database 
schema. 
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The  current  Machine  Tool  Metrology  model  (in  EXPRESS)  is  with  your  handout.  I will  put  up  just  the 
first  page  as  shown  on  slide  15.  We  can  see  the  "Machine  Tool  Performance"  entity  with  three  attributes- 
-File  Header,  Equipment  Artifact,  and  Test  Run.  The  circular,  or  rounded,  boxes  on  the  bottom  are 
references  to  other  pages  where  the  model  is  continued. 

MS.  KRULEWICH:  Will  the  plan  in  the  future  be  for  participants  to  enter  data  into  this  model?  Will 
there  be  a user  interface  that  prompts  me  for  these  questions?  Or  do  I have  to  actually  learn  this 
language? 

MR.  FRECHETTE:  No,  you  do  not  have  to  learn  the  language.  Ultimately,  what  we  want  to  do  to  is 
construct  a commercial  application.  To  accomplish  this,  we  need  to  communicate  how  the  data  should  be 
structured  and  the  desired  data  format  to  the  applications  developers.  This  is  where  the  EXPRESS 
language  (or  the  IDEF  10  language)  is  used.  The  initial  data  modeling  effort  attempts  to  determine  what 
data  is  required  and  the  desired  format  for  the  data.  This  step  is,  more  or  less,  the  development  a series  of 
lists.  We  may  use  IDEF  to  help  identify  what  data  is  required,  but  expertise  in  using  EXPRESS  is  not 
necessary.  I believe  participants  will  just  provide  files  representing  the  data  they  use.  As  the  data 
repository  is  developed,  data  entry  methods  will  be  refined. 

MS.  KRULEWICH:  One  other  question.  You  have  that  list  that  Steve  gave  you  of  all  the  important 
information.  It  seems  like  that  is  an  important  issue  - what  information  would  you  want  to  get  reported  in 
here.  It  might  be  interesting  to  do  a survey  of  IQL  software  and  the  different  existing  commercial 
packages  and  see  what  data  is  reported. 

MR.  FRECHETTE:  I agree  completely.  The  list  we  started  with  was,  as  you  know,  by  no  means 
definitive.  That  is  a very  difficult  process;  deciding  where  I am  going  to  define  the  data  and  where  is  the 
data  defined?  Do  I go  look  at  existing  applications  and  just  list  down  all  the  data  that  they  deal  with?  That 
is  one  part  of  the  process.  I think  that  this  is  what  this  is  all  about.  Talking  to  industry  experts  and  trying 
to  get  input  on  data  for  future  use.  One  thing  we  want  to  do  is  look  toward  the  future  and  look  at  what 
applications  might  be  doing.  And  it  is  my  opinion  that  a lot  of  the  people  in  this  room  are  really  cutting- 
edge  when  it  comes  to  that. 

MR.  CALLAHAN:  Dave  Hemerle  just  asked  me  a few  questions  which  I had  actually  thought  about 
earlier.  Who  is  going  to  own  this  database?  Who  is  going  to  pay  for  the  database?  Where  is  it  going  to 
reside?  Has  that  been  discussed? 

MR.  DONMEZ:  Well,  that  question  came  up  in  our  last  workshop,  and  I think  what  we  are  intending  to 
do  is  to  develop  the  structure  of  this  database,  develop  the  methodology,  decide  how  to  provide  access  to 
it,  and  hope  that  industry  will  take  these  structures  and  start  building  for  their  own  use.  Then,  somebody 
can  come  in  and  develop  a more  accessible  global  database.  That  issue  is  important,  but  I think 
companies  like  Caterpillar,  General  Electric,  and  General  Motors  would  be  more  interested  in  using  it  for 
their  own,  that  is,  if  they  see  that  it  is  advantageous.  Then  it  will  expand  to  other  companies,  maybe  as  a 
more  global  type  of  repository.  That  is  our  view. 

MR.  CALLAHAN:  Could  we  get  some  big  companies  to  comment  on  that? 

MR.  BISHOP:  What  I hope  would  happen  is  that  this  could  serve  as  a framework  for  all  the  vendors  out 
there  who  are  producing  software  products  so  we  do  not  have  to.  At  Boeing,  amass  data  elements  and 
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build  parsing  routines  for  each  and  every  package  that  comes  out.  We  could  have  a standard  that 
different  vendors  would  work  to.  That  is  what  I am  hoping  will  happen. 

MR.  FRECHETTE:  That  is  the  direction  in  which  we  should  be  headed.  NIST  can  act  as  a catalyst  by 
developing  a draft  data  structure  and  once  there  is  enough  momentum,  an  industry  group  will  get 
together  and  say,  "Okay,  now  we  need  to  step  back  and  do  a very  rigorous  data  mapping  exercise."  This 
will  lead  to  some  type  of  industry  standard,  a commercial  standard,  which  will  allow  software 
applications  to  exchange  information  and  to  users,  like  Caterpillar,  it  would  be  invisible.  Users  would  not 
have  to  develop  their  own  software  to  integrate  various  commercial  applications. 

MR.  CALLAGHAN:  I'm  wondering  whether  we  should  have  some  experimental  database  residing  at 
NIST? 

MR.  DONMEZ:  That's  what  we're  trying  to  do  right  now,  an  experimental  database. 

MR.  CALLAHAN:  But  what  I was  going  to  suggest  is  that  the  users  subscribe  to  that  by  providing 
information  and  you  just  dump  it  in  there  and  then  we  would  have  access  to  work  with  that  database  just 
for  experimental  purposes.  I think  some  kind  of  formal  structure  has  to  be  put  in  place  that  says,  "Okay, 
Boeing,  GE,  Pratt  and  Whitney  are  going  to  contribute  data  on,  for  example,  horizontal  boring  machines, 
and  then  they're  going  to  have  access  to  the  database.  The  other  piece  of  it  is  to  have  some  formal 
structure  to  get  that  data  into  the  repository  where  the  people  who  are  participating  are  going  to  have 
access  to  it. 

MS.  McMILLAN:  We  already  have  a data  model  and  database  and  data  entities  and  relationships  all 
lined  up.  I don’t  know  what  it  would  take,  but  I'd  like  to  share  input  with  you  so  that  we  don't  have  to 
change  things  later.  But  we've  been  working  on  it  for  a while  now  and  we've  got  something  that  we  think 
covers  everything  we've  seen  so  far. 

MR.  DONMEZ:  So,  we  need  your  input  on  the  discussion  right  now  that  we're  going  to  be  showing  some 
of  the  data  types  and  formats.  Hans  Soons  will  lead  that  discussion.  Then,  once  we  get  your  input,  we'll 
find  out  how  much  we're  off  and  what  type  of  modifications  we  need  to  do  in  order  to  come  to  a more 
standard  format. 

MS.  McMILLAN:  Well,  I would  not  run  anything  through  our  Legal  Department  yet. 

MR.  CALLAHAN:  That's  why  I raised  the  issue.  We  went  through  this  same  problem  about  15  years 
ago  relative  to  the  coordinate  measurement  machines.  All  the  builders  of  coordinate  measuring  machines 
were  going  to  submit  similar  kinds  of  information  to  the  B89  standards  committee  at  that  time  and  it  took 
around  three  years  of  legal  wrangling  to  be  able  to  get  even  just  a small  bit  of  that  data.  We  wanted  to  see 
how  well  the  B89  standard  was  working.  We've  got  the  same  problem  here.  We  want  to  see  how  well 
these  database  structures  are  going  to  work. 

MR.  DONMEZ:  We  are  aware  of  some  of  the  legal  problems  and  some  of  the  reluctance  from  the 
machine  tool  builders;  that  issue  came  up  in  the  last  meeting.  I think  at  this  point  we  are  not  going  to  be 
relying  on  machine  tool  builders  to  provide  the  data.  Instead,  we  are  relying  on  the  users  to  provide  the 
data.  The  way  to  protect  against  the  legal  issues  is  to  not  put  any  labels  to  the  machines.  There  will  be 
generic  names—Machine  A from  Company  B.  We  should  put  only  the  data  not  the  real  names  of  user 
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companies  nor  machine  builders. 

MR.  CALLAHAN:  When  will  you  be  able  to  start  shipping  raw  data  and  some  specifications  of  that  raw 
data  to  us?  Are  we  talking  about  something  that  you  could  start  today,  next  month,  six  months  from 
now? 

MR.  DONMEZ:  As  you'll  see  a little  later,  Larry  Welsch  will  show  you  an  experimental  repository  that 
we  have  been  playing  with  for  the  last  month  or  so.  There  are  some  data  in  that  repository  already. 

MR.  CALLAHAN:  I want  to  raise  one  other  question.  I've  got  probably  one  of  the  largest  repositories  of 
this  kind  of  information  in  the  country  right  now.  I have,  on  several  occasions,  gone  back  to  my 
customers  and  said,  "I  have  a bunch  of  data  from  General  Motors  I was  going  to  give  to  Steve  Patterson." 
They  went  back  and  went  through  their  legal  department  and  they  said,  "What's  in  it  for  General 
Motors?"  Without  an  answer,  they  didn't  give  us  the  data.  So,  what  I'm  searching  for  here  is  some  give 
and  take,  so  that  if  I put  a bunch  of  data  into  the  system  I have  access  to  do  something  with  that  database. 
I'm  sure  everybody  who  is  going  to  have  to  release  data  into  this  database  is  going  to  have  the  same 
problem.  Therefore,  it's  going  to  have  to  be  a give  and  take  situation.  So,  we  need  to  put  together  a 
structure  that  says,  "Okay,  if  I put  1 0,000  hours  work  of  data  into  this  system,  I'm  going  to  have  access  to 
information  on  100  machines  of  this  particular  configuration,  or  10  machines  of  that  configuration." 

MR.  DONMEZ:  Yes.  But  I think  when  we  put  data  in,  for  example,  we  should  not  associate  that  data  to 
GM  or  Cincinnati  Milacron. 

MR.  CALLAHAN:  Right.  I agree.  There  still  has  to  be  give  and  take. 

MR.  CHANDRASEKHARAN:  A couple  of  comments.  On  the  previous  one  that  you  talked  about,  who 
owns  this  database  or  how  it  gets  used,  there  is  a similar  effort  in  Europe  for  the  DIN  4000  standard  for 
tooling  information.  That  evolved  over  the  last  few  years  and  now  there  is  a company  called  SIM  that 
actually  sells  CD-ROMs,  which  they  update  using  the  database  format.  It's  working  really  good  in 
Europe  because  now  Kennametal,  Valenite  and  Sandvik,  in  Europe,  have  combined  together  and  formed 
a consortium  with  this  database  developer  and  they've  changed  the  database  structure  to  make  common 
data.  In  fact,  if  they  were  the  same  tools  that  we  manufacture,  it’s  three  times  as  much  data.  And  the 
database  starts  getting  huge.  Now  they've  leveraged  that  kind  of  work  and  they  have  formed  together  and 
it's  working  really  well  over  there.  Unfortunately,  it  hasn't  moved  into  the  United  States  as  much  as  we'd 
like. 

The  second  point  is  from  a user  perspective,  that  we  would  be  very  willing  to  put  data  into  a repository 
like  this  first,  because  we  learn  how  to  use  the  data.  Also,  we  learn  how  the  applications  coming  out  of 
data  like  this  can  work  and  what  benefit  it  has  to  a company  like  Caterpillar.  For  these  reasons,  as  long  as 
our  name  is  not  associated  with  the  data  we  put  in,  I think  we'd  be  very  willing  to  put  anything  into  it. 
We're  also  going  to  help  the  development  of  smaller  companies  like  what  SIM.  If  it's  cost-effective 
enough  we  might  just  take  the  entire  database  development  on  our  own.  A company  like  GM  or  Ford 
might  just  do  that,  whereas  a company  like  Caterpillar  might  just  choose  to  pay  an  annual  fee  to  get  the 
database  and  regular  updates  periodically  once  a month.  So  it's  just  an  evolving  business  which  has 
worked  really  well  in  Europe. 
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MR.  PATTERSON:  I think  it's  important  that  we  distinguish  several  things  that  we  could  be  doing  here. 
There  are  really  four  topics  that  seem  to  be  circulating  here  in  a perhaps  unfortunately  interchangeable 
way.  There  is  an  information  model  to  be  developed  about  the  process  itself.  Then  we've  been  talking 
about  the  design  of  the  database,  which  is  basically  a way  of  structuring  that  informational  model  in  a 
useful  way.  What  we  have  assumed,  but  haven't  identified  explicitly,  is  a file  format  for  the  interchange 
of  that  data,  which  is  an  additional  definition  thing.  And  then  what  we've  started  to  spin  up  to  high  order 
here  is  repository  management.  Now,  I would  offer  that  three  of  those  four  things  are  essentially 
technical  in  nature  and  there  is  no  roadblock  to  developing  them  and  they  have  significant  benefit  to  a 
wide  variety  of  us.  If  we  crash  on  the  shoals  of  politics  and  legalism  in  terms  of  maintaining  a large 
repository  of  data  in  a centralized  location,  that  makes  it  no  less  useful,  at  least  for  the  data  which  I'm 
perfectly  happy  to  send  to  IQL,  since  I'm  not  as  parsimonious  about  the  data  as  GE,  or  General  Motors,  or 
somebody  else  may  be.  The  results  are  still  highly  useful.  I hope  we  didn't  get  sidetracked  on  legal 
issues  when  we  probably  have  about  the  right  audience  in  this  group  to  make  an  awful  lot  of  progress  on 
the  three  technical  issues  in  front  of  us. 

MR.  DONMEZ:  Based  on  Steve's  classification,  information  models,  design  of  database  and  file  formats 
are  the  three  technical  issues  that  we  should  concentrate  on.  We  should  leave  aside  the  fourth  item, 
repository  management,  for  now. 
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Machine  Tool  Metrology 
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COMMUNICATION  AND  STORAGE  OF  MACHINE  TOOL  DATA 

H.  Soons 


I would  like  to  discuss  information  elements  and  possible  formats  that  can  be  used  to  communicate  and 
store  the  properties  of  a machine  tool.  The  goal  is  to  assess,  update,  store,  and  retrieve  machine  tool  data 
necessary  for  virtual  machining.  You  received  two  documents  that  accompany  this  presentation.  One  is 
called  "Some  Notes  on  the  Machine  Tool  Database,"  and  the  other  one  is  "Communication  and  Storage  of 
Performance  Evaluation  Data." 

To  determine  what  data  is  needed,  we  need  to  define  virtual  machining.  In  a broad  sense  a virtual 
machine  tool  is  a model,  usually  implemented  in  software,  that  predicts  the  output  of  the  machining 
process  by  simulating  the  actions  of  the  machine  tool  in  response  to  the  part  program  and  the 
environment.  As  we  discussed  already  this  morning,  the  output  of  a virtual  machine  tool  can  be  more 
than  the  tolerances  of  the  part.  Other  possible  results  are  the  time  required  to  make  the  part,  the 
verification  of  the  part  program,  tool  life,  and  maintenance  schedule. 

A critical  enabler  to  virtual  machining  is  an  efficient  access  to  relevant  data  on  the  part  we  want  to  make, 
the  method  used  to  make  it,  the  machine  tools  that  we  are  going  to  use,  the  tools,  and,  of  course,  the 
machine  environment.  In  this  presentation  I would  like  to  concentrate  on  the  third  issue:  what 
information  do  we  need  about  the  machine  tool. 

Machine  tool  data  can  be  divided  into  two  parts.  One  class  is  data  that  applies  to  all  machines  of  a series. 
Usually  these  are  specifications  or  design  data  published  by  the  machine  tool  builder.  The  first  document 
that  you  received,  "Some  Notes  on  the  Machine  Tool  Database,"  contains  a list  of  information  elements 
that  belong  to  this  class.  This  data  addresses  the  classification  of  the  machine  such  as:  is  it  a lathe  or  a 
grinder,  is  it  a vertical  or  horizontal  machine,  or  how  many  spindles  and  axes  of  motion  does  the  machine 
have.  It  contains  the  information  that  we  need  to  build  the  kinematic  model  of  the  machine;  information 
on  the  axes  and  spindles,  such  as  allowed  feed  rates,  range,  minimum  increments;  information  about  tool 
and  workpiece  management,  for  example  the  kind  of  pallets  used;  information  about  the  controller  such 
as  the  available  error  compensation  parameters,  which  parameters  are  accessible  to  the  user,  enabled 
canned  cycles.  Finally,  there  are  the  accuracy  specifications,  often  stated  as  a set  of  numbers  that 
summarize  the  effects  of  certain  error  sources.  Accuracy  specifications  and  means  to  verify  them  are 
defined  by  performance  evaluation  standards  such  as  the  ANSI  B5.54  and  the  ISO  230  series.  Not  all 
machine  tool  manufacturers  follow  these  standards  when  specifying  the  accuracy  of  their  machines. 

Sometimes  the  machine  data  available  for  virtual  machining  is  limited  to  this  class.  For  example,  virtual 
machining  can  be  used  to  select  the  machine  tool  that  has  to  be  purchased  to  manufacture  certain  parts. 

In  this  case,  detailed  performance  data  is  usually  not  available.  Indeed  the  machine  often  has  not  yet  been 
built. 

The  second  class  of  machine  data  is  that  which  applies  to  a specific  machine  at  a specific  site.  This  data 
comprises  the  compensation  parameters  of  the  machine,  adjustments  that  have  been  made  to  that 
machine,  any  special  modifications,  and  of  course,  actual  performance  evaluation  data.  We  prefer  a 
layered  approach  in  the  storage  of  this  performance  data.  At  the  lowest  level  there  is  the  raw 
measurement  data.  At  higher  levels,  performance  parameters  are  stored.  An  example  of  this  would  be 
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the  squareness  error  of  two  axes.  Such  a squareness  error  parameter  will  have  a pointer  to  the  test  data 
used  to  calculate  it,  e.g.,  the  data  of  two  straightness  measurements.  The  motivation  for  this  approach  is 
that  we  do  not  want  to  lose  the  raw  measurement  data.  Machine  tool  error  modeling  and  performance 
monitoring  is  still  an  evolving  field.  It  is  therefore  not  prudent  to  summarize  and  discard  the 
measurement  data  based  on  the  currently  available  parameters. 

I would  like  to  focus  this  presentation  on  how  to  store  and  communicate  the  description  and  measurement 
data  of  performance  evaluations.  There  exists  a variety  of  software  packages  for  the  performance 
evaluation  of  machine  tools.  Many  of  these  are  made  by  the  manufacturer  of  a particular  measurement 
device,  such  as  a laser  interferometer  or  a ballbar,  and  tailored  to  that  particular  instrument.  The  software 
packages  use  different  data  models  and  associated  formats  to  store  the  measurement  data.  Sometimes 
these  formats  are  proprietary.  The  data  is  hidden  in  a binary  file  whose  content  can  only  be  retrieved  by 
the  software  and  in  a form  dictated  by  the  software.  Other  packages  use  a more  accessible  format  in 
ASCII. 

Not  all  relevant  information  about  a certain  test  is  assessed  and  stored  in  particular  information  about  the 
measurement  set-up.  Usually,  the  only  information  that  is  stored  is  the  information  required  to  produce 
the  graphs  and  numbers  specified  in  the  various  standards.  For  example,  most  software  packages  do  not 
store  or  ask  where  in  the  machine  workspace  the  test  is  executed  or  what  the  effective  tool  offset  is.  This 
information  is  essential  for  many  analyses  that  go  beyond  the  graphs  and  numbers  specified  in  the 
standards,  especially  when  results  of  several  tests  are  combined  or  compared.  In  practice,  this 
information  is  often  lost  or  recorded  in  notebooks  that  have  a life  separate  from  that  of  the  data  files. 

Most  formats  are  tailored  towards  a specific  type  of  performance  test.  If  the  device  is  used  for  a test  not 
found  in  the  standards,  or  for  a recently  standardized  test,  the  format  is  often  not  useful  or  incomplete. 

What  is  necessary  is  a unified  definition  of  information  elements  and  a related  data  format  to  allow  for: 
first,  the  straightforward  interchange  of  performance  test  data.  Second,  the  communication  and  storage  of 
all  relevant  information,  not  just  the  information,  needed  to  produce  a certain  performance  parameter  or 
graph.  And  third,  the  description  of  non-standard ized  tests. 

The  information  elements  and  data  format  should  enable  the  reconstruction  of  the  nature  of  the  test  and 
why,  when,  and  by  whom  it  was  conducted.  They  should  enable  the  identification  of  the  equipment  that 
was  used  to  assess  the  data  and  which  buttons  were  being  pushed.  They  should  enable  a reconstruction  of 
the  measurement  set-up,  the  machine  movements,  the  applied  warm-up  procedure,  and  the  environmental 
conditions. 

Other  criteria  are:  an  efficient  description  of  both  standardized  and  non-standardized  tests  plus  an 
efficient  communication  and  storage  of  user-defined  data.  Both  criteria  are  related  to  the  fact  that 
machine  tool  error  modeling,  performance  evaluation  testing,  and  condition  monitoring  are  evolving. 
What  is  important  tomorrow  may  not  be  important  today.  Also  it  is  difficult  if  not  impossible  to 
anticipate  all  the  information  elements  that  may  be  important  for  a particular  application  or  user. 

The  recording  of  all  information  relevant  to  a particular  test  should  not  be  enforced.  Sometimes,  only  a 
quick  check  is  desired.  Furthermore,  it  is  not  necessary  to  record  all  the  information  that  would  be 
required  for  an  error  compensation  procedure.  The  format  associated  with  the  information  elements 
should  have  a man-readable  equivalent  in  ASCII,  so  that  it  is  multi-platform.  Finally,  the  organization 
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and  nature  of  the  information  elements  should  be  such  that  queries  can  be  handled  very  efficiently. 

This  slide  shows  an  example  of  a data  file  generated  by  a commercial  data  acquisition  package.  The  data 
describes  the  measurement  results  and  some  set-up  information  of  a circular  ballbar  test.  The  used  format 
is  such  that  the  information  elements  can  be  easily  identified.  As  is  usually  the  case,  the  test  and 
measurement  data  are  organized  into  runs.  A run  is  a certain  motion  pattern  of  the  machine  during  which 
errors  are  measured.  A performance  evaluation  test  consists  of  several  runs  which  can  differ  in  minor 
parameters.  In  this  case,  runs  differ  in  the  direction  of  motion:  clockwise  or  counter-clockwise.  The  run 
data  is  preceded  by  a general  header  that  contains  common  information  for  all  the  runs.  Examples  of 
these  are:  name  of  the  machine  and  operator,  date,  information  about  the  equipment,  for  example  whether 
the  ballbar  has  a calibrated  length  or  not. 

I would  now  like  to  discuss  some  ideas  on  the  data  structure  and  required  information  elements  to 
describe  performance  evaluation  data  using  a file  format  as  an  example.  Measurement  data  is  organized 
into  runs.  Each  run  has  a header  that  only  applies  to  the  data  in  that  run.  The  header  of  a run  can  modify 
the  parameters  contained  in  the  general  header.  For  example,  the  general  header  can  specify  a feed  rate 
of  2 000  mm/min.  The  header  of  run  2 might  modify  this  to  1 000  mm/min.  This  feedrate  of  1 000 
mm/min  then  only  applies  to  run  2. 

The  data  is  organized  into  data  blocks  each  with  a keyword  followed  by  data.  For  example,  a block  can 
contain  the  keyword  "Operator"  followed  by  the  name  of  the  operator.  A dictionary  of  keywords  with 
definitions  has  to  be  constructed.  There  should  also  be  a mechanism  for  user  defined  keywords  as  is 
shown  in  this  example.  The  presence  of  information  elements  should  not  be  enforced,  unless  they  are 
necessary.  The  sequence  of  the  information  elements  should  be  arbitrary  when  possible. 

A mechanism  is  needed  to  organize  data  into  structures  or  sets,  such  as  allowing  multiple  data  blocks  into 
the  data  field  of  a data  block.  Also,  a mechanism  is  needed  to  give  a data  set  a name  and  refer  to  it.  In 
this  example  we  define  a device,  which  is  a read-out  device  that  measures  temperature.  Some 
information  is  supplied  about  the  device,  such  as  the  units,  the  resolution  setting,  and  the  manufacturer. 
Here  we  define  a temperature  sensor  that  uses  the  previously  defined  read-out  device.  Extra  information 
is  given  that  pertains  to  this  particular  sensor,  such  as  the  channel  number  and  where  the  sensor  is 
located. 

Defaults  have  to  be  defined.  For  example,  all  units  are  metric  unless  specified  otherwise.  If  angles  are 
measured  and  specified  in  inches  per  foot,  there  should  be  an  appropriate  statement. 

A mechanism  is  needed  to  format  data,  storing  it  in  tabular  form.  This  is  an  example  for  a spindle  drift 
test.  The  data  has  a header  that  defines  what  each  column  of  the  table  contains.  Items  of  the  header  may 
be  labels  that  point  to  devices  that  are  specified  elsewhere.  In  this  example,  the  table  contains  time, 
spindle  speed,  an  indicator  reader,  and  two  temperatures.  After  the  header  follows  the  data.  A symbol 
will  be  needed  to  identify  missing  data. 

A challenge  in  describing  a performance  evaluation  test  is  that  various  items  are  measured  or  changed 
during  the  test  at  different  times.  Plus,  a mechanism  is  needed  to  synchronize  these  events.  For  example, 
a drift  test  may  involve  the  measurement  of  drift  and  temperature  over  time,  as  well  as  a change  in 
spindle  speed  at  a certain  instance.  There  are  several  possible  mechanisms  to  describe  the  sequence  of 
events.  Probably  several  of  these  specifications  should  be  allowed. 
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The  first  example  is  to  list  all  items  that  are  either  measured  or  subject  to  change  in  one  table.  This 
format  is,  for  instance,  suitable  for  drift  measurements  where  temperature  and  drift  are  measured  every 
minute.  Note  that  one  column  contains  the  spindle  speed.  Another  method  is  to  chronologically  record 
each  event.  For  example,  the  first  entry  is  a change  in  spindle  speed.  The  temperature  and  indicator 
readings  are  recorded  for  a certain  time.  Then  the  spindle  speed  is  changed  and  temperature  and  indicator 
readings  are  resumed. 

Another  method  is  to  sort  events  into  blocks:  one  block  with  spindle  speed  data,  one  block  with 
temperature  data,  and  one  block  with  indicator  readings.  Synchronization  can  be  achieved  using  a time 
stamp  as  is  done  on  the  left  side.  The  example  on  the  right  shows  an  implicit  synchronization  where  the 
temperature  data  applies  to  all  measurements  of  the  run  in  which  it  is  recorded.  If  more  than  one 
temperature  reading  is  present,  the  readings  are  assumed  to  be  distributed  over  the  complete  run. 

In  the  next  slides,  I would  like  to  discuss  the  information  elements  that  are  needed  to  describe  a 
performance  evaluation  test.  I already  mentioned  that  the  data  is  organized  into  measurement  runs  and  a 
general  header  that  contains  data  pertaining  to  all  the  runs.  Now,  I would  like  to  start  with  a more 
detailed  description  of  this  header. 

First,  the  format  used  to  store  the  data  should  be  specified.  Second,  a record  that  identifies  the  machine  is 
needed.  The  operator  needs  to  be  identified  and  the  date  or  dates  when  the  test  was  executed.  A 
formalized  method  is  needed  to  describe  the  test  so  that  queries  to  a particular  kind  of  test  can  be  handled 
efficiently.  A start  can  be  made  by  categorizing  all  tests  in  the  current  standards.  The  test  description 
would  include  the  standard  used.  A statement  as  to  why  the  test  was  conducted  can  be  useful. 

An  important  section  of  the  general  header  is  a description  of  the  test  equipment,  both  measurement 
devices  and  artifacts  such  as  ring  gauges  and  straightedges.  The  description  of  a measurement  device 
should  contain  the  used  settings  and  properties  of  that  device,  so  that  the  precise  meaning  of  a 
measurement  value  can  be  reconstructed.  Examples  are:  units,  resolution,  applied  compensations,  settle 
time,  number  of  samples  averaged,  and  sample  frequency.  For  artifacts,  the  data  may  involve  the 
dimensions  of  the  reference  features  of  the  artifact,  and  the  effective  coefficient  of  expansion.  The  data 
of  equipment  and  artifacts  should  contain  identification  information  that  points  to  more  detailed 
information  stored  elsewhere.  Finally,  the  test  equipment  section  contains  set-up  information.  I will 
explain  that  in  more  detail  later  on. 

A section  of  the  general  header  may  describe  the  status  of  the  machine,  such  as  applied  compensations, 
whether  or  not  the  coolant  was  on,  if  any  axes  were  clamped  and  the  applied  warm-up  procedure. 
Statements  and  measurement  data  about  the  machine  environment  may  also  be  included  in  the  header.  If 
detailed  information  is  available,  like  multiple  sensor  readings  over  time,  it  can  also  be  included  in  the 
data  section  of  a run.  Finally,  the  general  header  will  possibly  have  a comments  section  organized  using 
keywords 

During  the  final  part  of  this  presentation,  I would  like  to  discuss  the  information  elements  needed  to 
describe  the  measurement  set-up  and  the  machine  motion  pattern.  Performance  tests  can  be  classified 
into  groups  that  share  a similar  measurement  set-up  and  motion  pattern.  The  first  class  are  tests  where 
the  machine  is  moved  along  a line  in  the  machine  axes  space.  Examples  of  such  tests  are  the  roll,  pitch, 
yaw,  straightness  and  positional  error  measurements  of  an  axis,  and  diagonal  displacement  tests. 
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The  second  class  consists  of  the  “stationary”  tests.  Here  errors  in  the  position  of  the  tool  relative  to  the 
table  are  measured  at  one  point  in  the  machine  workspace.  Between  measurements,  machine  axes  may  be 
moved,  after  which  the  tool  is  returned  to  the  measurement  point.  An  example  of  such  a test  is  the 
environmental  temperature  variation  test.  It  involves  measurement  of  the  drift  in  the  position  and 
orientation  of  the  tool  over  time.  Other  examples  are  the  spindle  thermal  stability  tests,  composite  drift 
tests,  subsystem  repeatability  tests,  and  spindle  axis  of  rotation  measurements. 

Other  classes  are  circular  contouring  tests,  compliance  and  hysteresis  tests,  and  machining  tests.  Note 
that  this  classification  does  not  address  the  purpose  of  the  test  nor  the  components  tested,  but  rather  the 
set-up  and  machine  motion  pattern. 

As  an  example,  I would  like  to  discuss  the  information  elements  required  to  describe  a performance 
evaluation  test  that  involves  machine  motion  along  a line.  First,  the  machine  motion  pattern  needs  to  be 
defined.  This  requires  specification  of  the  used  feed  rate  between  the  target  points,  or  an  indication  that 
the  machine  is  moved  manually.  For  each  run,  the  approach  direction  has  to  be  specified,  which  can  be  a 
positive  approach,  negative  approach,  or  a pelgrim  approach.  There  are  several  methods  to  specify  the 
target  points.  One  method  is  to  record  the  position  of  all  the  machine  axes  at  each  target  point.  Another 
is  to  define  a start  position,  the  direction  of  positive  machine  motion,  and  target  the  amount  of  travel 
along  the  line  for  each.  The  direction  can  be  defined  in  several  ways:  using  a direction  vector,  by 
specifying  the  axis  that  is  moved,  or  by  specifying  a start  and  end  position.  In  the  example  at  the  bottom 
of  the  slide,  the  target  points  are  defined  by  a start  point,  an  end  point  and  a sampling  interval.  In  case  of 
a dynamic  measurement,  a sampling  frequency  can  be  used. 

In  addition  to  the  motion  pattern  of  the  machine,  the  measurement  set-up  needs  to  be  defined.  A test  can 
involve  several  sensors.  For  example,  there  are  set-ups  where  angular,  straightness,  and  positioning 
errors  are  measured  simultaneously.  Each  sensor  requires  the  specification  of  whether  it  measures  an 
angular  or  a displacement  error,  which  machine  component  is  the  target  and  which  the  reference,  this  is 
especially  important  for  machines  with  multiple  spindles  and  turrets,  the  direction  of  positive  error 
motion  of  the  target,  and  the  effective  tool  offset  associated  with  the  sensor.  The  orientation  of  the  used 
reference,  such  as  a straightedge,  may  be  important,  for  example,  for  reversal  purposes. 

The  next  slide  shows  the  example  of  a Z-axis  pitch  measurement  of  a lathe.  In  this  block  the  used 
measurement  device  is  specified,  including  the  set-up.  The  device  has  been  given  the  name  “Laser”.  So, 
if  a data  table  contains  the  label  “Laser”  in  the  header,  we  know  that  the  respective  data  has  been  obtained 
using  the  device  specified  in  this  block.  Various  device-specific  settings  are  specified  such  as:  the  nature 
of  the  measurand,  in  this  case  an  angle,  the  direction  of  positive  error  motion,  in  this  case  a rotation 
around  the  positive  Y-axis,  the  units  of  the  measurand,  the  sample  frequency  before  averaging,  the 
number  of  samples  averaged,  the  settling  time,  the  machine  components  to  which  the  reference  and  target 
are  attached,  and  the  effective  tool  offset. 

I hope  that  this  presentation  gave  you  an  impression  of  information  elements  and  possible  formats  that 
can  be  used  to  communicate  and  store  performance  data  of  machine  tools.  I focused  on  the  measurement 
data  and  description  of  performance  tests.  Further  formalization  requires  choices  and  more  information. 
For  both,  we  need  your  participation.  Today  we  would  like  to  know  if  further  formalization  of 
information  elements  and  formats  is  a useful  effort,  if  the  chosen  approach  and  focus  are  right,  if  essential 
elements  are  missing,  and  what  we  need  to  change.  We  also  are  very  interested  in  the  kind  of  information 
you  currently  record  during  performance  tests,  the  formats  used,  and  what  you  do  with  the  data. 
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DISCUSSION 


MR.  CALLAGHAN:  Do  you  see  this  as  a file-based  system  or  a database  system?  Has  that  not  yet  been 
determined? 

MR.  SOONS:  Our  primary  focus  was  to  identify  the  information  required  to  describe  a performance 
evaluation  test  and  its  results.  Regarding  the  format,  I focused  on  a system  where  all  data  of  a particular 
performance  evaluation  test  can  be  contained  in  one  file.  We  hope  that  by  defining  the  format  in  the  right 
way,  for  example  by  using  some  of  the  EXPRESS  formalism,  it  will  also  be  useful  in  the  design  of  a 
database  that  contains  many  performance  evaluation  measurements.  In  that  case,  the  file  format  may 
only  be  used  to  communicate  performance  evaluation  data. 

MR.  CALLAGHAN:  One  of  the  problems  I have  is,  obviously,  the  limitations  of  files.  Also,  the  file 
naming  convention  is  a huge  handicap.  At  Renishaw,  for  example,  I ran  100  machines  and  I ran  ballbar 
tests  on  a weekly  basis.  It  is  very  clear  that  we  had  to  develop  some  method  of  organizing  all  that  data. 
There  is  no  way  to  do  it  with  the  conventional  file  naming  conventions.  You  have  to  translate  it  into  a 
database  format.  So,  that  is  the  direction  in  which  I have  been  heading.  So  I was  just  wondering  if, 
perhaps,  that  is  the  direction  that  you  all  want  to  consider.  When  you  are  talking  about  a large  number  of 
machines  and  a large  amount  of  data,  then  a file  format  does  not  usually  satisfy  performance.  Also,  for 
the  textual  file  formats,  we  have  to  build  programs  to  strip  the  data  out  of  these  files  to  put  it  into  the 
database.  So  if  we  can  agree  on  some  methodology  where  we  could  already  be  in  an  Access  type  format 
database,  or  something,  then  that  would  go  a long  way  toward  helping  us  organize  our  data.  As  opposed 
to  staying  in  an  ASCII  file  format  structure. 

MR.  SOONS:  I was  trying  to  do  both.  I find  file  formats  very  useful  to  store  data  when  measurements 
are  taken,  as  a backup  of  unprocessed  data,  and  aim  to  communicate  data.  I do  not  think  transporting  the 
data  into  a database  will  be  a major  problem. 

MS.  McMILLAN:  When  you  have  such  large  amounts  of  data  I think  it  can  be.  It  is  for  us. 

MR.  CALLAGHAN:  The  file  formats  tie  you  back  to  the  vendor- specific  software  in  the  analysis  tools 
which  is  not  always  where  you  want  to  be.  We  would  like  to  be  able  to  extract  the  data  and  use  it  either 
way;  we  could  use  the  vendor  software  to  process  it  or  we  could  use  our  own  tools  to  process  the  data. 

Renishaw  uses  one  format  and  API  probably  uses  another.  If  I want  to  use  both  tools,  or  combine  data 
from  both  tools,  I have  a problem.  Both  talk  about  roll,  pitch,  yaw  and  squareness,  but  the  way  they 
format  them  in  their  files  is  totally  different.  In  many  cases  we  have  multiple  packages  in-house. 

MR.  FRECHETTE:  What  if  those  vendors  gave  you  the  choice  of  a standard  format? 

MR.  CALLAGHAN:  Precisely.  I am  hoping  that  we  can  agree  on  what  such  a file  format  might  look 
like.  So  when  you  talk  about  roll,  roll  looks  like  this,  defined  characters  and  defined  field  size.  So  that 
no  matter  where  you  get  the  data  from,  it  will  always  look  the  same. 

MR.  SOONS:  This  is  one  of  the  things  we  hope  to  achieve,  and  that  manufacturers  of  software  and 
measurement  devices  will  take  it  over.  When  this  is  achieved,  I think  that  translation  into  a database  is 
not  much  of  a problem,  because  you  only  have  to  do  it  once  for  each  file. 
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MR.  CALLAGHAN:  That  would  work.  That  would  be  a good  step  in  the  right  direction  for  us. 

MR.  CALLAHAN:  I think  you  need  to  specify  the  file  formats  to  even  understand  what  we  have  to  put 
in  the  database.  Some  very  important  issues  have  been  mentioned  today.  Issues  that  become  important 
as  you  begin  to  use  this  data  more  extensively  than  we  have  in  the  past.  With  the  file  format  we  can  play 
for  a while  before  we  build  this  big  database. 

MR.  CALLAGHAN:  I am  not  sure  every  vendor  is  going  to  want  to  incorporate  every  single  element 
that  every  other  vendor  has.  There  should  be  some  nucleus. 

MR.  SOONS:  That  is  why  I think  it  is  important  not  to  enforce  the  presence  of  all  information  elements. 
We  want  to  define  the  keywords,  definitions,  and  possible  data  structures  and  formats  to  be  able  to 
include  information,  not  to  enforce  it. 

MR.  FRECHETTE:  You  are  going  to  run  into  a problem  with  that  because,  if  somebody  is  expecting  a 
sample  frequency  then  their  system  is  going  to  crash  if  it  is  not  in  the  file.  You  need  to  institute  a 
minimum  subset  where  at  least  you  will  get  the  functionality  of  the  applications.  That  is  what  we  have 
done  in  the  auto  industry;  we  have  established  a minimum  subset  for  configuration  management  data  and 
then,  if  you  don’t  want  the  entire  set,  you  do  not  need  to  deal  with  it. 

MR.  SOONS:  If  we  abandon  the  file  format,  are  we  not  abandoning  a large  part  of  the  customer  base? 
The  use  of  databases  to  analyze  and  store  performance  evaluation  data  is  not  common.  Often,  only  the 
software  that  came  with  the  measurement  device  is  used  to  analyze  the  data. 

MR.  WELSCH:  There  is  an  even  bigger  problem.  The  database  community  itself  has  not  agreed  upon 
interchange  standards  and  that  is  a very  serious  problem.  What  they  have  agreed  upon  is  a query 
language,  so  we  are  kind  of  stuck  with  defining  an  interchange  format. 

MS.  McMILLAN:  Do  we  have  any  standards  yet  for  data  exchange? 

QUESTION:  Well  what  about  STEP?  They  are  a series  of  protocols  that  apply  to  a variety  of  things.  A 
review  of  those  might  be  useful  in  this  area. 

MR.  FRECHETTE:  I don't  think  there  are  any  existing  application  protocols  that  cover  this  domain. 

MR.  WELSCH:  It  is  a matter  of  the  level  of  abstraction  of  the  problem.  If  you  look  way  down  low,  there 
are  many  standards  for  doing  this,  and  if  you  start  looking  way  up  high,  towards  only  machine  tools,  I 
don't  think  there  are  any.  Where  we  are  in  that  spectrum  is  any  place  you  want  to  pick,  and  there  is  not 
one  that  is  quite  right. 

MR.  MA:  Back  to  the  database.  I like  to  group  the  information  into  three  groups.  One  is  machine- 
related,  one  instrument-related,  and  one  measurement-related.  A vendor  could  already  store  most  of  the 
instrument-related  information.  All  three  groups  would  make  the  measurement  file  pretty  immense.  The 
three  groups  can  be  stored  separately  and  merged  together  when  put  into  a database. 

MR.  PATTERSON:  I don’t  think  that  is  inconsistent  with  what  is  being  done  here.  However,  I was 
thinking  about  how  we  would  implement  this  internally.  One  of  the  beauties  of  working  from  an 
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information  model  downward  in  both  the  database  and  the  exchange  format,  with  a common  dictionary 
for  the  terms,  is  that  I have  all  the  pieces  together.  The  dictionary  for  the  terms  gives  me  the  references  I 
need  for  a standard  query  language.  The  file  format  lets  me  send  something,  and  then  I can  organize  the 
data  your  way  in  my  internal  database.  I can  put  an  identifier  with  the  measurement  instrument  and  use  a 
relational  database  property  to  store  that  information  in  one  place  once.  So  in  my  database,  I will  have 
the  table  of  instruments,  the  table  of  machines,  and  the  table  of  measurements.  Then,  in  proper  and 
normal  relational  database  fashion,  when  I need  to  send  an  experimental  result  to  Debbie,  who  has  a 
different  set  of  local  instruments  and  the  like,  I can  append  the  header  in  the  way  Hans  has  laid  it  out  so 
that  the  full  set  of  information  gets  transmitted  on  the  exchange.  And,  if  there  is  some  consistency  in  the 
data  validation,  that  can  be  done  in  an  unambiguous  and  common  way. 

MR.  WELSCH:  One  of  the  very  real  problems  that  I have  observed  in  other  fields,  and  I am  not  from  the 
manufacturing  field  initially,  is  the  issue  of  consistency  that  he  just  raised.  How  do  we  arrive  at  that 
consistency  in  the  dictionary  with  the  very  subtle  differences  in  meanings  that  different  manufacturers 
will  apply  to  the  same  name  that  we,  as  humans,  deal  with  very  easily  but  software  has  a miserable  time 
dealing  with? 

MR.  DONMEZ:  That  is  why  manufacturers  should  be  involved. 

MR.  CHANDRASEKHARAN:  A good  instance  for  that  is  chatter  or  stability.  How  do  you  tell  a 
computer  what  is  chatter  or  what  is  stability?  You  never  get  that  threshold  point  defined  mathematically. 
Some  things  are  difficult  to  put  numbers  on. 

MR.  MA:  I have  a question  on  the  definition  of  the  data.  If  you  look  at  the  data,  what  does  it  mean? 
Different  people  a have  different  interpretations.  People  give  us  data  and  often  we  have  to  ask  what  it 
means.  What  is  the  X,Y,  and  Z?  There  are  two  definitions.  One  is  from  the  plot  coordinates,  another 
from  the  controller.  Sometimes  the  controller  does  not  have  right-hand  coordinates.  But  in  software  we 
usually  apply  right-hand  coordinates.  Different  people  give  different  definitions.  For  example,  with  the 
pitch,  yaw  and  roll,  which  is  pitch?  Therefore  I think,  in  addition  to  the  format,  the  data  itself  should  have 
a clear  definition. 

MR.  SOONS:  Indeed  we  need  definitions  at  several  levels.  First,  the  meaning  of  the  keywords  that 
identify  the  information  contained  in  a data  field  need  to  be  precisely  defined.  Then  the  format  of  the 
data  field  needs  to  be  defined,  for  example  if  a date  is  going  to  be  in  a day,  month,  year  format  or  a 
month,  day,  year  format.  As  you  mentioned,  some  terms  and  tests  are  not  well  defined  in  the  standards,  a 
typical  example  is  the  sign  of  positive  error  motions.  We  will  have  to  have  a close  look  at  that. 

MR.  DONMEZ:  For  example  to  resolve  the  confusion  about  the  definition  of  pitch  and  yaw,  we  may 
have  to  define  the  plane  of  the  angle. 

Is  there  anything  in  the  list  that  you  have  seen  that  seems  to  be  missing? 

MR.  CALLAGHAN:  There  are  a few  things  that  we  do  not  have,  and  we  probably  have  a few  things  that 
you  do  not  have,  but  we  are  pretty  much  on  the  same  track.  I think  this  is  a really  good  start  and  it 
encompasses  much  of  what  we  have  to  do.  We  have  many  internal  things  that  we  have  to  deal  with  in 
terms  of  the  organizations  in  which  our  machines  are  and  other  kinds  of  things  that  a group  like  this  will 
not  have  to  deal  with. 
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MS.  McMILLAN:  I think  we  need  to  take  a closer  look  at  the  different  options  for  data  modeling. 

MR.  DONMEZ:  What  kind  of  data  modeling  tools  do  you  use? 

MS.  McMILLAN:  We  have  two  different  kinds.  We  were  using  Accelerator  and  we  just  purchased  a 
new  one.  Both  of  these  packages  are  IDEF-based.  I am  anxious  to  find  out  more  about  the  data 
modeling.  Maybe  have  a group  lay  out  a proposed  high-level  model  and  start  going  down.  That  is  how 
we  did  it. 

MR.  FRECHETTE:  But  you  have  a model  now? 

MR.  CALLAGHAN:  Yes,  but  it  is  somewhat  specific  to  our  particular  application.  It  encompasses 
machine  measurement,  but  it  also  encompasses  many  other  factors  that  would  be  specific  to  Boeing,  as 
opposed  to,  perhaps,  other  vendors. 

MR.  FRECHETTE:  How  long  did  it  take  you  to  develop  that  model? 

MS.  McMILLAN:  It  has  been  off  and  on  for  probably  two  years  now  because  of  funding  issues  and  the 
amount  of  people  that  we  can  put  on  it.  The  focused  time  is  probably  at  least  six  months,  but  it  has  not 
been  a big  effort,  just  a couple  of  people. 

MR.  CALLAGHAN:  Obviously,  we  want  to  make  sure  we  are  paralleling  this  effort  as  much  as  possible, 
and  we  can  learn  from  things  that  we  do  not  have. 

MR.  DONMEZ:  We  want  to  learn  from  your  experience  too. 

MS.  McMILLAN:  As  technology  moves  on,  I think  you  want  to  be  less  and  less  file-based  because  even 
the  smaller  vendors  can  use  packages  like  Access  and  make  a nice  relational  database  out  of  that.  You 
can  do  a better  analysis  quicker,  and  get  to  the  information  that  you  need  quicker.  We  set  up  little 
committees  to  look  at  different  tools  to  do  this. 

QUESTION:  Is  your  model  something  you  can  share  easily,  taking  away  the  Boeing-specific  part  of  it? 

MR.  BISHOP:  She's  got  to  run  it  through  Legal  and  Public  Relations.  We  don't  know  right  now. 

MR.  MA:  What  did  you  use  for  your  model?  Did  you  concentrate  on  just  one  machine  to  see  which 
machine  can  be  used  for  what  parts? 

MR.  CALLAGHAN:  Yes,  and  we  monitor  the  health  of  the  machines.  We  use  statistical  tools  on  our 
data. 

MR.  CALLAHAN:  We  monitor  over  time  and  we  look  at  all  the  different  tests  as  to  what  is  happening 
over  time.  We  run  frequency  tests  as  well  as  the  baseline  measurements.  We  have  many  different  tests, 
almost  everything  in  the  B5.54.  We  keep  track  of  what  tests  we  run.  All  the  things  that  he  had  outlined 
are  pretty  much  in  our  system. 

MR.  SOONS:  Have  you  already  put  the  mechanisms  in  place  to  combine  and  correlate  data  so  that  if,  for 


-71- 


example,  you  have  positional,  squareness,  pitch,  yaw  and  roll  measurements  you  try  to  see  if  that 
correlates  to  what  you  are  seeing  in  other  tests  or  your  parts.  Also  regarding  variations  in  time. 

MS.  McMILLAN:  That  is  the  next  phase.  And  that  will  need  more  of  an  analysis,  which  things  need  to 
be  correlated  and  which  ones  don't,  and  which  variation  factors  are  more  important  than  others.  I foresee 
it  getting  knowledge-base  oriented. 

MR.  CALLAGHAN:  We  need  to  get  our  data  together  so  we  can  look  at  the  spectrum  of  the  information. 
We  don’t  have  that  capability  right  now.  The  data  resides  on  various  files,  in  various  places,  and  in 
various  systems.  Our  intent  is  to  bring  it  all  together  so  we  can  start  looking  at  all  of  our  machines 
simultaneously.  We  have  not  done  the  kind  of  analysis  that  you're  talking  about,  but  we  don't  see  an  easy 
way  to  do  that  until  we  have  all  the  data  at  our  fingertips. 

MR.  DONMEZ:  Any  other  comments? 

MR.  CALLAGHAN:  Can  we  create  a mechanism  for  the  exchanges  that  are  going  to  be  necessary  in 
order  to  compile  a more  complete  list? 

MR.  DONMEZ:  Yes.  Let's  wait  until  after  the  coffee  break  when  Larry  shows  the  web  site.  Maybe  we 
can  put  some  data  in  the  web  site  and  communicate  through  the  web. 

MS.  McMILLAN:  Does  NIST  already  have  a data  definition  list,  a data  dictionary  of  standard  terms? 

MR.  SOONS:  The  two  documents  that  I described  are  our  first  effort  towards  that  goal.  They  try  to  give 
an  overview  of  the  information  elements  required  to  store  the  results  of  performance  evaluation  tests. 
They  do  not  yet  give  a formal  list  of  keywords,  definitions,  and  relations.  That  will  be  the  next  step. 

MR.  CALLAGHAN:  It's  a really  good  start  though. 
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Hans  A.  Soons 

Automated  Produoion  Technology  Division 
Manorial  Institute  of  Standards  and  Technology 

February  16, 1997 


Virtual  machine  tool: 

A model,  usually  implemented  in  software,  (fiat  predicts  an 
output  of  the  machining  process  by  simulating  the  actions 
erf  the  machine  tool  In  response  to  the  part  program  and  Ihe 
environment. 

Output: 

• Tolerances  part 

• Tune  required  to  make  the  part 
» verification  part  program 
» Tod  fife 


Required  information 


Critical  enabler  Is  efficient  access  to  relevant  date  on: 

• The  part  (geometry,  tolerances.  material) 

• The  preces*  ptafl  (part  program,  setup  and  fDrtunrtfl) 

• The  machine  looks) 

• The  look*) 

• The  machine  strwanmerd 

Machine  tool  Information: 

• Data  that  appBe*  to  machines  of  a series 

'Gesi^i  data':  CtanAcatron,  kinematic  model.  Jti  and  spir.dle  data, 
tool  and  workpiece  management.  controOer,  accuracy  speofieabana. .. 

• Data  that  appBes  to  a specific  machine 

• Compensations,  adjustments 

* Performance  evaluation  data  (tests,  parts) 


Layered  approach:  raw  data  -»  performance  parameters 


Performance  evaluation  data 


Currently: 

• Many  formats 

• Not  ad  relevant  information  is  stared 

• Application  fariled  to  standanSzed  tests 

Unified  definition  for  a flexible  data  format: 

» Straightforward  tnierehmge  of  test  data 
« Commracabon  and  storage  of  ad  relevera  nfcrmahon 
» Non-standard  tests 


Criteria  information  elements  and  format 


• Enable  reconstruction  of: 

• The  nature  of  9>e  lest  and  why.  when,  and  by  whom 

• The  equipment  used  and  settings 

• The  measurement  setup 

• The  status  and  motion  pattern  of  the  machine 

• Measurement  data 

• Environmental  corxSeons 

• Efficient  description  of  standanfized  and  specal  tests 

• Efficient  commurYcahon  and  storage  of  user  defined  data 

• No  enforcement  of  information 

• Man-readable  equrvaient  hi  ASCII 

• Efficient  handhng  of  queries 


. EXPRESS 
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General  information 


• Tea  equipment  (measurement  devices  and  artifacts) 

• tdensftcaiion.  type,  manufacturer 

• settings 

» epplied  compensations  and  used  sensorts) 

• settle  bme  and  trigger  window 

» number  of  san-pies  averaged  and  sample  frequency 

• rangefresolution  settng 

• unit 

• scatefacJor 

• sign 

• software  and  software  version 

• properties 

• dimensions,  geometry,  reference  traturefs) 

• material  effective  coefficient  of  expansion 


• setup 


General  information 


• Status  of  the  machine 

• applied  compensations 

« coolant 

» damped  axes 

« appbed  warm-up  procedure 

• Status  of  the  machine  environment 

• Comments 

Setup  and  machine  motion  pattern 

Measurements  along  a line 

Classification  according  to  setup  and  motion  pattern: 

• Angular  or  displacement  measurements  along  a line': 

Motion  pattern 

• geometric  aecKacy  of  an  a*k  (roB,  prtrji,  yaw,  straightness,  positional) 

• Feed  rata  (or  manual  motion) 

• drift  teal  of  an  axis 

• Approach  direction: 

• diagonal  displacement  test 

• Positive 

• critical  alignments 

♦ Negative 

« Stationary  tests: 

• Positive  pdgnm 

• ETVE 

♦ N^gatrv*  p4gr»m 

• spBidfc  thermal  stability. 

• moving  axes  drift,  compose  drift. 

• Target  points 

• toot  change  repeatability,  axis  repeatability. 

v , 

• tpbvSe  error  motion 

3 jfi  ic;  jja  3 

* Circular  contouring  tests 

: 35  220  o 

• Compliance  and  hysteresis  tests 

Lad 

Measurements  along  a line 

Measurements  along  a line 

Start  position  :*5  .tJ,  ft  13',.  Zi  r?C„  it  5 

Setup  and  measurand(s): 

X;  i.  >t  5.  u c.  xr  s 
•-  ? zs't*U 

• angular  or  displacement  error 

« 6 

• direction  positive  error  motion 

• effective  tool  offset 

tm 

• machine  components  whose  rotative  error  motion  is  measured 

Cm 

• orientation  (e.g..  for  reversal  purposes) 

Tne  (Erection  can  be  defnad  using 

• fixtumg 

• A tSredkxt  vector  Dxr«witc*»:  Xx  t.  Tt  s,  2:  c.  xi  a 

• An  axis  OeMpnaUyi  tc-c««?ion:  x 

Note  a measurand  can  involve  a combination  of  devices  and  artifacts 

• An  end  pOM&Oft  Lr\o  tro«a;tioci:  ki  trZa  t-i  u;.  ztc.  A;  t 

T*T<i2«r»t 

«utt  2:  iC.  ti  >?*.  Ct  ?20.  A:  3 

fcV3  X>  3C,  T-»  7?;,  ir  s\*5.  Ai  5 

£nn 
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Measurements  along  a line 


Example:  2-axis  pitch  measurement  on  a lathe 

:>V*’  lM*t 


n&s*;  baNur-t  cere 
till 

2cf'V*r«  vcoltti  2,1 
S*w«i C.CS 

r.t**7>**ncyt  *2 

JU;«,rervr*  osr  Jcind*o  -* 
or:?  Tyrr^t  ; 

Tool  atiz+zt  xa  Ti  c*  2i  -;o 


Discussion 


Information  elements  and  formats  to 
store  and  communicate  performance  data 

• Is  further  formaSiing  of  Information  elements  and  formats  useful 

• How  do  we  tnaease  parfiopabon? 

• Are  (he  chosen  approach  and  focus  nghP 

• Are  essential  elements  missng? 

» What  information  Oo  you  record  about  performance  tesis? 

• Which  formats  do  you  use? 

• Vtfiat  do  you  do  with  me  data? 
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DEMONSTRATION  OF  A WEB-BASED  EXPERIMENTAL  REPOSITORY 

L.  Welsch 


I like  to  start  with  some  background  on  myself  so  you  know  where  I am  coming  from.  Up  until  this  past 
August,  I was  a manager  for  NIST  in  the  Information  Technology  Laboratory.  I worked  primarily  on  the 
issues  of  document  interchange.  I currently  work  for  NIST’s  Manufacturing  Engineering  Laboratory  and  I 
have  been  working  on  technology  aspects  related  to  manufacturing  since  last  August. 

Mr.  Donmez  asked  me  to  relate  this  work  closely  with  Mr.  Frechette’s  presentation.  I am  speaking  as  a 
programmer  today.  I do  not  understand  the  manufacturing  aspects,  so  if  misuse  a term,  please  let  me 


Why  Perform  Information  Modeling? 


Translate  expert’s  knowledge  into  form  that 
can  be  understood  by  application  developers. 

Application 

Domain  Experts  Developers 


know.  I will  be  the  contact  for  a while  as  far  as  this  particular  project  in  terms  of  the  web  development 
prototype  is  concerned.  To  test  our  repository,  we  need  as  much  data  as  possible.  You  may  contact  me  at 
301-975-3198  or  by  e-mailing  LWelsch@nist.gov  if  you  want  to  ship  data  to  me. 


About  six  or  seven  weeks  ago,  I met  with  Mr.  Donmez  and  he  started  asking,  "What's  real?  You  are 
talking  about  all  this  EXPRESS.  What's  real?  Can  you  do  something  to  make  this  real?" 

I finally  got  Mr.  Donmez’s  point  and  said,  "Using  Web  technology,  we  can  build  realistic  examples 
quickly.” 

I talked  about  being  able  to  show  some  retrieval  with  web  technology  with  about  six  files.  This 
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presentation  represents  a team  effort.  Ms.  Ling  built  one  of  the  system  components,  Mr.  Soons  wrote  all 
of  the  analysis  code,  Mr.  Gilsinn  provided  reality  checks,  and  Mr.  Wilkin  put  together  the  structure  of  the 
site  and  built  most  of  the  Web  Site  you  are  going  to  see.  I built  the  infrastructure. 

Six  weeks  ago  we  did  not  even  have  a computer  to  run  on.  We  (1)  ordered  memory,  (2)  bought  software, 
and  (3)  configured  a computer  system.  We  built  this  system  in  less  than  six  weeks.  Please  bear  with  me. 
Many  links  will  not  work  right. 


DEMONSTRATION 

I am  moving  from  the  Sensor  Systems  group  home  page  to  the  home  page  of  the  repository. 


National  Institute  of  Standards  and 
Technology 


Machine  Tool  Performance  Data  Repository 
_ Machine  Tool  Types 


Turning 

Centers 

Machining 

Centers 

Grinding 

EDM 

Search  for  Machine: 

Under  Construction 

Reset  Machine  Name 

Send  Machine  Data  Request 

Please  Send  Comments  to  Allcan  Donmez 

l wgrcnsl 


Current  verwn  motiifrd  on  3/2 1/97 


We  divided  the  world  into  different  classes  of  machine  tool  types.  Content  is  associated  with  each  link. 
Today  the  content  is  very  incomplete.  We  will  look  at  one  particular  path  that  I know  is  mostly  present.1 

We  are  going  to  look  at  Machining  Centers.  Note  that  Machining  Centers  is  sub-divided  into  vertical  and 


1 A path  is  a collection  of  pages.  Links  written  in  HTML  connect  the  pages  to  each  other.  HTML 
(Hyper-Text  Markup  Language)  is  a language  for  designing  web  pages. 
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it*  kcpaH’Urv  --  Vertical  Machining  Ccnu 


tetp:  total  r~r<  uapld . tsteL^o*' A x't 


Machining  Centers 


Vertical  Machining  Centers 


Horizontal  Machining  Centers 


NAMT  Repository  Home  Page 

horizontal  machining  centers. 


Vertical  Machining  Centers 


Vertical  Machine  A 

Vertical  Machine*  B 

Vertical  Machine  C 


krtara  to  Magbntm?  CVotrtx  Pagr 

jtrtara  To  Mgjw»lf«rv  How  Rgg 

I pdmwl  5WW 


Next  we  select  vertical  machining  centers. 


From  vertical  machining  centers  we  select  "Vertical  Machine  B."  Then,  we  get  the  data  in  Data  Set 


Vertical  Machine  B 


Pact  Vi  N'timN-r  1 

graph  1 ,nif 

kcuticsi  li-itllktr  Dam 


Wrttyq  1 1 N r^tv>d  MwXnwt  < 

Krtrun  1-  Mm-tmwnii  < 

I f 


Number  1 . The  data  is  stored  as  a Quattro  Pro  spread  sheet. 
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Dumping  the  data  from  the  server  system  at  NIST  to  this  system,  is  an  important  step.  Because  the  data  is 
in  the  form  of  a spread  sheet,  the  user  may  use  the  spread  sheet  to  analyze  the  data. 


Vertical  Machine  B 


?>■»*  Sci  Number  1 

EHiphl.uif 

Rainer  Bollh^r  Data 


1 " rv  r,iy 


I pdsMl  9JJWT 


The  next  capability  we  will  demonstrate  is  viewing  an  analysis  that  has  already  been  performed. 
Returning  to  Virtual  Machine  B,  we  will  now  download  graphl.gif. 


Difference  between  Averaged  & Raw  Data 
081794.pl 


£ 0.08  1 
-i  0.06  - 

£ 0.04  - 

e o.o2  - 
•|  0 « 
— -0.02  ■ 
8 -0.04  - 
<5  -0.06  - 
(d  -0.08  ■ 
n i . 

• 

>1 

• 

1 

1 

1 

• 

1 

-■« 

• 

r j*  \ -■  -j>- 

L L _V-  — * .ir. . _v. 

m m m oj  o®  ! O- o I o o 

«*»•  2ED'«iwi»  **«■*_•  *»' 

H3A  ^ I ! 

- *• 

A iU*.  A A.*  • A.*.  m • A.  M 

* * 

. t » i * . . 

Q 01 

0 5 10  15  20 


Time  (minutes) 

5th  set  in  average  » 4th  set  in  average  - 3rd  set  in  average 
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The  last  thing  that  we  wanted  to  do  was  to  show  a search  followed  by  an  analysis  of  the  data  sets  found. 
Mr.  Soons  put  together  the  form  below.  The  form  allows  users  to  set  values  on  parameters  that  one  might 


NAMT  Machine  Tool  Pcrl'crrriKJOcc  Data  Repository...  Page  t of  3 

NAMT  Machine  Tool  Performance  Data  Repository 

DallBar  Data  Request  Form 

Plane: 

OXY  O XZ  O YZ  WAaty  inane 
Bnllbar  length: 

OIOO  0150  0 200  0250  0*00  0450  0600  ^Any 
Length 

Inclination:  [o  | 

Measurement  Typo: 

O Static  ODynamie  #Any  Type 
Feed  Rase: 

jfr  ~~|  and  | ~ ] mm  / min 

Direction  of  Measurements: 

OOoekwiso  OCounter  Clockwise  O Bidireclional  >4^  Any 
Direction 

Position  Center:  X between  }o  ~]  and  [ »»oo  | mm 

V between  [ o ~|  and  { mm 

Z between  \u  | and  | »ono  ~[  mm 

Tool  Length:  Between  p | and  [sw»'  | mm 

Select  Sturt  Date  of  I>u t a Request: 

l-^^nT  1 "II-  1 T~  1 

Select  Hnd  Dale  of  Pitta  Request: 

| | IP  |~j|.«.7  [ j 


liml  of  Form. 


K clmr»  T-  V 

tteiatxa.  r-^  vriKtii  Mm.  hitting  jjmtmJbc 


I'lMiMlMi  &/2S9 7 


H/a/07  3:16:11  PM 

use  to  search  a data  base  containing  ballbar2  data  sets.  One  important  question,  that  we  need  your  help  on, 
is:  What  parameters  should  be  used  to  search  the  database?  We  do  not  expect  this  question  answered 
today.  There  are  only  two  parameters  we  can  search  with  today,  and  one  is  the  plane.  We  will  select  the 
X-Z  plane.  The  other  parameter  is  measurement  type.  Measurement  type  may  be  either  static  or  dynamic. 
We  will  select  dynamic. 

Part  of  what  makes  Web  technology  attractive  is  building  the  user  interface.  User  interface  construction  is 
a complicated  part  of  application  development.  For  example,  Volumes  1 and  2 of  the  Microsoft®  Win32 


bailhaj2.pl  at  www-mlrdb.aptd.nisLgov 

Starting  Search 
6 data  sec.  match 

Please  Select  the  data  set  you  want: 
Select  Data: 

O RUN  1 02 1 C» 

OR  UN  102  IB 

ORUN102ID 

ORUN102IE 

Onewstat 

ORUN1021F 

sjtrvi  [submit  Data  Request 


Page  1 of  1 


2Ballbar  data  refers  to  data  collected  with  a type  of  machine  tool  measurement  device  called  a 
telescoping  ballbar. 
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Programmer’s  Reference  is  almost  entirely  devoted  to  user  interface  issues.3  Also  built,  was  the  structure 
of  the  form  using  Web  technology.  I used  the  structure  Mr.  Wilkin  built  to  generate  what  you  see. 


Mr.  Wilkin  built  the  query  form.  The  programs  I built  used  the  form  to  construct  the  query.  The  programs 
did  a search  of  about  7 or  8 files.  We  slightly  modified  the  representation  of  the  data  that  searched.  The 
system  analyzed  the  raw  data  in  its  original  form  as  collected  by  the  ballbar. 


Now,  the  big  thing  that  I didn't  want  to  do,  and  that  isn't  quite  working,  is  the  actual  analysis  part  of  the 
system.  As  I was  sitting  here  talking,  MATLAB®  was  running.  MATLAB  executed  an  analysis  program.4 

Dynamic  Ballbar  Measurement 


Dxu  file:  runl02lh_nb 

Operator.  Neil  Wttkia 

MjchiTtt  Monarch 

Ballbar  Serial:  13611 

Date.  18:02  Gel  21  1904 

CTircularuv : 85.9  um 
error  02.4  tun 

Vlax  emir  5.*.5  um 

Error  bc«  radiuv  < 14.1  um  i 

X ofhec  02  um 

V offset*.  03  um 

Herd:  30U)0  mnVmin 

Sample  frequency:  75.0  Hr. 
RnlEbar  length:  150J)mm 

I'u.  Iinntnqi  angle:  0/1  <Jc£ 

Data  * arc  9Q.0  deg 

Data  cad:  270.0  drg 

Data  overdxw*.  3.0  ifc* 

*unxCW:2 

Ruox  CCW:  1 

3rU  erwer  removed:  NO 

Best  PvJrov  removal  NO 

»— i n 


*».:/■/  Si. 


yTTt' 


Mr.  Soons  wrote  the  analysis  program.  MATLAB,  in  real-time,  generated  the  text  data  that  you  see  in  the 
figure  above.  MATLAB  also  generated  the  same  graphical  figure  that  you  see  above.  However,  the 
system  is  displaying  a different  figure  than  the  one  MATLAB  generated.  This  is  due  to  not  understanding 
how  all  of  the  different  technologies  we  used  worked  together.5 


One  questions  I have  is:  What  capabilities  for  analysis  should  be  in  the  repository?  How  robust  should 
the  repository  be? 


3Win32  is  the  name  of  the  application  programmer  interface  for  the  Microsoft  Windows  95  and 
NT  operating  environments.  That  so  much  of  the  description  of  the  interface  is  devoted  to  the 
user  interface,  provides  insight  into  how  difficult  application  user  interfaces  are  to  design. 

4The  MATLAB  system  executes  programs  written  in  the  MATLAB  language.  The  programs 
may  be  either  written  in  real  time  by  the  programmer,  or  written  and  stored  as  “.m”  files. 

5Since  giving  this  presentation  we  have  developed  a better  understanding  of  how  the  technologies 
work  together  and  fixed  this  problem. 
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DISCUSSION 


MR.  CALLAGHAN:  Are  you  accessing  a file,  or  generating  some  sort  of  file?  I'm  not  sure  how  you're 
doing  that.  Is  this  a bitmap  that  I'm  seeing  here,  or  an  actual  generation? 

MR.  WELSCH:  You're  seeing  a graphic  file  that  I created.  I wish  you  were  seeing  the  actual  generation. 
That's  just  a matter  of  time. 

MR.  CALLAGHAN:  Do  you  think  you  can  do  that?  Can  you  actually  generate  it  on  the  web  page? 

MR.  WELSCH:  Yes.  As  a matter  of  fact,  the  biggest  issue  is  that  we  happen  to  be  generating  Postscript® 
and  if  we  wanted  to  dump  the  Postscript  image  down  to  Ghostscript6,  we  could  be  doing  the  imaging  with 
the  MATLAB  generated  image  in  real  time.  Mr.  Soons  felt  that  it  was  important  to  have  the  image  on  the 
same  page  with  the  description.  Unfortunately,  the  one  part  of  the  system  we  were  not  able  to  get  working 
in  time  for  the  demo  was  the  conversion  of  Postscript  to  GIF7  or  JPEG.8  Once  the  graphic  is  in  either  GIF 
or  JPEG  format  we  can  combine  the  Graphic  with  the  HTML  page  and  ship  the  page  to  the  browser.  The 
image,  in  the  sense  of  the  postscript  file  from  which  this  image  was  created,  was  generated  just  now  as  I 
was  talking.  The  system  attempted  to  convert  the  image  to  GIF.  Unfortunately,  there  is  a bug  and  the 
system  failed. 

MS.  McMILLAN:  Was  it  built  in  Unix™  or  was  that  the  picture  itself? 

MR.  WELSCH:  Was  what  built  in  Unix? 

MS.  McMILLAN:  The  actual  graphic. 

MR.  WELSCH:  The  image  was  created  running  MATLAB  on  an  Windows  NT™  machine  in  Postscript. 
The  actual  code  that  I'm  using  to  do  the  interfacing  is  written  in  Perl,  which  comes  from  the  Unix 
community.  I am  also  using  a version  of  KomShell  developed  by  the  Mortice  Kern  Systems  as  the  main 
shell  interface. 

MR.  CALLAGHAN:  One  last  question.  Are  you  accessing  the  raw  files  in  this  native  language  that  this 
data  was  taken  in?  How  is  that  being  reported?  Do  you  have  directories  out  there  that  just  store  the  files 
for  each  of  these,  and  if  so,  how  do  you  do  that? 

MR.  WELSCH:  The  search  is  being  done  on  some  files  that  I actually  did  a little  bit  of  manipulation  on.  I 
created  a separate  directory  and  broke  each  file  into  two  parts.  One  part  was  the  header  information  and 
the  second  part  was  what  I believe  Mr.  Soons  called  each  "run."  We  used  Perl  to  do  the  search.  It’s  a 
simple  linear  search  that  is  easy  to  build,  but  very  computation  intensive.  I believe  we  will  need  to  build 


6GhostScript  is  the  name  of  a Postscript  imaging  engine  readily  available  on  the  Internet. 

7GIF  - Graphics  Interchange  Format  is  a bitmap  graphics  format  developed  by  CompuServe  Inc. 

8JPEG  - Joint  Photographic  Experts  Group  is  a bitmap  graphics  format  developed  by  the  ISO 
standards  committee  with  the  same  name. 
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indices  and  use  a database  engine  for  the  search. 

We  are  providing  the  MATLAB  programs  with  the  original  file  of  raw  data.  I believe  that  there  will  come 
a point  when  we  will  freeze  this  work  and  create  a new  design. 

That  concludes  all  the  remarks  that  I had  and  the  demo  that  I wanted  to  show. 

MR.  CALLAGHAN:  Is  this  accessible  on  the  web,  or  will  it  be  in  the  near  future  accessible  to  us,  from 
outside?  I’d  like  to  be  able  to  access  it.  Could  you  post  it? 

MR.  WELSCH:  This  is  a Netscape  browser.  Right  now  we  are  limiting  access  through  the  server.  I 
would  certainly  like  to  see  work  that  I contributed  to  being  used.  I think  it's  absolutely  necessary  to  get 
feedback  first.  I hope  to  be  able  to  make  the  program  accessible,  however,  as  to  what  time  frame,  I can't 
answer  you  on  that. 

MR.  DONMEZ:  We  have  an  internal  policy  that  whatever  we  put  in  the  public  domain  we  have  to  go 
through  some  management  approval  process.  So,  as  soon  as  we  complete  those,  were  able  to  open  up  a 
little  bit. 

MR.  CALLAGHAN:  Will  this  be  a good  candidate  for  that  then,  as  far  as  you're  concerned? 

MR.  WELSCH:  Yes.  Without  question.  I'd  like  to  see  it  out  there. 

MR.  BLOMQUIST:  Why  don't  we  get  a show  of  interest  on  how  many  people  would  be  interested  in 
using  it? 

MS.  McMILLAN:  Well,  we  definitely  want  to  look  at  it. 

MR.  CALLAGHAN:  I don't  know  about  using,  but  I'd  definitely  investigate  it. 

MR.  MCCLURE:  I have  a question.  Up  to  now  I think  we've  been  talking  about  something  that's  a data 
storage  and  retrieval  system.  Why  is  the  analysis  provided?  Why  would  you  store  something  like 
MATLAB  in  the  background  that  you  could  go  in  and  treat  as  a column  of  numbers?  Why  would  you  do 
that? 

MR.  DONMEZ:  There  are  several  reasons.  I think  what  we  would  like  to  do  is  look  at  the  future,  how  are 
these  repositories  to  be  used  and,  if  we  can  do  some  of  the  experimentation  of  the  usage,  then  we  can 
modify  the  repository  structure  accordingly.  If  we  don't  do  any  of  these  tests  now,  then  the  repository  that 
is  going  to  be  built  may  be  not  adequate  and  we  want  to  test  these.  The  MATLAB  that  we  use  is  for 
prototyping  purposes  only. 

MR.  MCCLURE:  I have  an  answer  to  that.  I think  you  can  extend  the  use  of  the  web  site  to  promote  the 
development  of  standards.  I mean,  we're  talking  about  standards  that  are  static,  too  slow  to  develop,  non- 
existent and  we've  got  to  fill  those  gaps.  This  process  can  go  on  until  actually  the  site  establishes  a series 
of  links,  so  that  certified  packages  could  be  accessed  directly  and  maybe  more  than  once.  It  sure  would 
add  incentive  to  the  vendors  to  get  active  and  put  more  into  it  than  they  are  now  in  working  towards  some 
kind  of  an  agreement  on  standards.  It  took  ten  years  to  develop  a digital  filter  for  the  surface  finish  data, 
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still  not  every  company  has  fully  agreed  to  it.  There  is  the  problem  of  the  software  that  we  had  with  the 
software  on  measuring  machines. 

MR.  CHANDRASEKHARAN:  I have  a question  on  the  development  of  this  web  site  and  making  it 
available  publicly.  Now,  as  a participant  in  this  project,  are  we  (1)  gaining  anything  out  of  this  by  making 
this  open  to  the  public,  (2)  is  it  going  to  be  "public"  limited  to  the  participants  of  this  project,  or  (3)  is  it 
going  to  be  publicly  available  to  anyone  that  comes  on  board  later  on? 

MR.  WELSCH:  I'd  like  to  take  my  stab  at  that  as  a developer,  not  just  strictly  as  a programmer. 

Receiving  1 0,000  comments  on  something  is  not  very  useful.  Opening  up  so  that  we  can  receive  a few 
comments  from  those  people  who  are  expert  in  the  field  and  who  want  to  see  this  type  of  work  occur,  can 
be  tremendously  beneficial  in  the  sense  of  the  development.  At  this  particular  phase,  I,  as  a developer,  am 
looking  for  a community  such  as  represented  here  to  start  giving  us  feedback  back  and  forth. 

Now,  I think  in  terms  of  the  end,  we're  not  going  to  be  in  the  data  repository  business.  We  certainly  want 
somebody  to  come  in  and  make  this  into  a commercial  product.  That  would  be  great  to  see  that  happen, 
just  as  it  would  be  great  to  see  the  standards  work  stimulated,  and  I believe  the  term  was,  "short-circuited" 
by  that  type  of  an  investment.  And  you  had  a second  part  to  your  question? 

MR.  CHANDRASEKHARAN:  The  other  one  is,  is  the  best  bet  for  us  to  validate  the  definitions  of  the 
data  that  we're  going  through  and  establishing  the  scope,  in  which  case  the  investment  of  the  man-hours 
that  go  into  validation  and  developing  it— and  that  relates  back  to  what  the  gentleman  was  saying  about 
developing  links  where  it  goes  off  to  certify  people— and  you  know  that's  a classic  way  of  people 
developing  algorithms  and  scheduling  and  things  like  that.  You  have  problems  against  which  you 
benchmark  how  you  do  things  and  that's  essentially  what  we're  doing.  If  we  put  in  data,  let's  say  baseline 
data,  with  stripped  off  headers  from  Caterpillar,  Boeing,  and  GE,  and  somebody  wants  to  develop  tools, 
they  can  use  it  as  data.  That  has  positive  points  and  negative  points.  However,  is  there  a mechanism,  or 
is  there  something  in  the  pipeline  to  figure  out  the  charter  of  what  we're  trying  to  do?  What  is  the  scope? 

MR.  WELSCH:  As  a developer,  that  is  precisely  where  I would  like  to  see  this  go.  I really  want  to  see  this 
be  a type  of  stimulus,  and/or  type  of  catalyst,  for  industry.  In  broad  terms,  that  type  of  catalyst  is  what 
NIST  is  all  about.  The  next  steps  as  to  what  and  where  we  want  to  go  are  something  that  we  need  to 
discuss  and  we  need  to  listen  to  you  about.  If  that  is  high  on  your  priority  list,  that’s  where  we  will  head 
from  my  perspective. 

MR.  DONMEZ:  What  we'd  like  to  do  is  to  experiment  with  this  repository  by  having  the  data  from  people 
like  yourselves  to  see  where  the  shortcomings  are.  As  Larry  pointed  out,  this  particular  repository  is  not 
going  to  be  the  same  six  months  from  now.  It's  going  to  continuously  change,  and  we  will  be  testing 
continuously  with  the  data  that  you  are  providing. 

MR.  BLOMQUIST:  I think  Larry  has  a good  point  by  saying  he'd  rather  have  50  intelligent  comments 
than  1 0,000  from  the  masses.  So  how  do  we  do  that?  By  making  people  want  to  participate  as  members 
of  a consortium  that  has  no  cost  to  them.  Hopefully,  we  can  do  some  filtering  so  we  don't  have  the  entire 
world. 

MR.  CALLAGHAN:  This  morning,  I suggested  a place  for  members  to  deposit  some  data.  What  kinds  of 
data  do  you  accept? 


-85- 


MR.  WELSCH:  Right  now  the  types  of  data  that  we  have  are  a collection  of  ballbar  data,  an  assortment  of 
spreadsheets  and  some  graphs.  Now,  I'm  a computer  buff  and  C language  programmer.  One  of  my 
particular  interests  in  this  project,  as  a computer  person,  is  the  question  of  how  robust  an  interface  can  I 
build  for  accepting  data  in  different  forms.  That  is  an  open,  very  difficult  problem,  for  in  the  sense  of 
what  type  of  data  we  want  to  accept  right  now,  I don't  have  a good  answer.  And  yet,  the  first  person  who 
gives  me  data  will  be  the  first  one  that  I'll  try  to  put. 

MR.  ZIEGERT:  I'm  a little  unclear  as  to  what  value  lays  with  regards  to  having  a specific,  national 
repository  of  tests.  You  can  have  two  machine  tools  by  the  same  manufacturer  sitting  side-by-side  in  a 
facility,  and  each  one  is  going  to  have  different  results  to  these  tests  depending  on  how  that  machine  tool 
was  assembled  and  what  has  transpired  as  far  as  maintenance  history  . What's  the  value  of  having  a 
national  repository  of  data  that's  specific  to  a particular  machine  tool? 

MS.  McMILLAN:  Well,  I don’t  want  there  to  be  national  repository.  Although,  I do  want  tools  to  help  me 
do  what  I need  to  do.  Furthermore,  it  would  be  great  if  a consortium  would  help  develop  those  tools 
because  then  I know  I'm  in  the  right  direction. 

MR.  DONMEZ:  This  is  nothing  like  a national  repository.  As  was  mentioned  earlier,  we're  trying  to 
establish  some  structures  and  methodologies  of  how  to  store  this  information,  and  how  to  get  access  to  it 
and  analyze  it.  As  we  said  before,  there  are  two  reasons  why  companies  want  to  use  this  information:  (1) 
to  simulate  their  processes  and  (2)  to  find  out  their  capabilities.  Additionally,  from  the  research 
perspective,  it  gives  us  a lot  of  data  to  test  our  models  and  their  robustness,  though  it  doesn't  have  to  be  a 
national  repository.  Based  on  the  structures  and  definitions  we're  proposing  and  will  be  generated  within 
this  kind  of  consortium,  everybody  should  be  able  to  duplicate  their  own  repositories  according  to  their 
needs. 

There  will  be  a repository  which  we  will  be  developing  with  the  help  of  the  members  here,  and  everyone 
else  who  will  provide  help.  This  united  effort  would  then  result  in  an  experimental  repository  to  test  the 
ideas  and  concepts.  Caterpillar,  Boeing,  and  others  will  then  create  their  own  repositories  based  on  these 
standard  formats  and  their  needs.  In  turn,  they  can  share  their  repositories  with  their  suppliers  or  ask  their 
suppliers  to  put  their  information  in  that  repository  to  find  out  whether  or  not  they  have  a capability  for  a 
given  product.  It  is  therefore  the  users  decision  how  to  use  these  type  of  repositories.  If  we  have  the 
infrastructure  defined,  then  everyone  can  do  what  they  want  to  do.  The  software  developers  will 
eventually  develop  their  software  based  on  these  data  structures. 

MR.  ZIEGERT:  One  issue  I see  with  people  contributing  data  to  you,  Larry,  is  that  it's  kind  of  a cart- 
horse problem.  A lot  of  data  exists  and  it  exists  in  all  kinds  of  different  formats  and  structures  so  in  order 
for  me,  Boeing  Wichita,  or  anyone  else  to  send  you  data,  you  have  to  be  able  to  make  sense  of  it  and 
know  what  it  means.  Essentially,  we  have  to  convert  it  into  the  format  that  you'd  like  to  see  it  in.  So  we 
can't  send  you  data  until  we  know  what  that  format  is  and  you're  saying  you  can't  create  the  format  until 
you  have  the  data.  So,  where  do  we  start? 

MR.  WELSCH:  From  my  perspective,  we  start  by  taking  a look  at  the  specifications  that  you  have  for  the 
data.  Now,  I know  is  that  if  the  data  happens  to  be  in  ASCII  files  or  happens  to  be  easily  converted  to 
them,  there  are  many  tools  out  there  for  merging  the  data  and  putting  it  into  a database. 

You're  absolutely  right  that  specifications  are  needed  and  I would  like  to  see  examples  of  what  is  being 
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done  using  the  tools  that  we  currently  have  available,  try  to  put  it  into  a data  repository  for  prototyping.  If 
I make  some  mistakes,  I don't  really  care.  The  question  is:  can  we  learn  from  attempting  to  actually  do  it? 
I'm  going  to  work  with  you  and  with  these  specifications  that  you  currently  have. 

MR.  PATTERSON:  Am  I correct  that  you  presently  have  the  software  to  take  data  in  the  format  which 
Hans  outlined  earlier  in  this  meeting? 

MR.  WELSCH:  Yes. 

MR.  PATTERSON:  Okay.  We  also  have  at  least  two  of  the  major  data  formats  represented  in  the  crowd 
here.  Many  of  us  have  data  in  the  form  of  either  API  or  IQL  formats.  Are  you  suggesting  that  if  the  file 
formats  were  made  available,  that  overnight  you'd  be  able  to  take  data  from  any  of  those  three  formats  if 
they  give  you  the  data  and  the  format  definitions? 

MR.  WELSCH:  Yes. 

MR.  PATTERSON:  Would  it  be  fair  to  ask  if  those  format  definitions  could  be  made  available? 

MR.  MA:  Oh  yes,  I can  work  on  that  with  Larry. 

MR.  PATTERSON:  That  means  I can  send  you  my  IQL  data  tomorrow  after  I get  home? 

MR.  WELSCH:  Actually,  I'd  like  to  start  the  discussions  with  you  early  next  week  about  it  and  how  to 
receive  it.  From  the  time-frame  of  these  types  of  projects,  the  answer  is  yes.  We  have  to  start  making 
progress  now,  otherwise  I don't  think  it's  going  to  happen. 

MR.  PATTERSON:  I guess  I'm  suggesting  that  those  are  some  fairly  concrete  steps  that  would  represent  a 
significant  step  forward  and  give  us  some  experience  with  moving  data  around.  Inconsequentially  this 
might  up  the  ante  towards  pressuring  some  of  the  other  players  to  make  their  data  formats  available  for  the 
same  purpose. 

MR.  MA:  Yes.  I spoke  with  Hans  earlier.  I think  we'd  like  to  combine  our  efforts  with  the  NIST  format. 
Our  data  is  ASCII  readable.  Also,  we'd  like  to  provide  what  is  necessary.  Additionally,  if  this  is  really  the 
format  that  people  believe  in,  we'd  like  to  put  some  effort  into  it. 

MR.  WELSCH:  As  far  as  this  being  the  way  to  go,  I don't  know.  This  is  to  experiment  with  different 
approaches  so  we  can  determine  what  doesn't  work.  The  data  transfer  is  certainly  a major  problem  and,  as 
our  previous  speaker  mentioned,  the  consistency  of  both  the  dictionaries  and  the  meanings  of  the  terms 
starts  to  become  absolutely  vital. 

MR.  ZIEGERT:  Momentarily,  I want  to  get  back  to  the  question  about  the  national  repository.  I am  not  a 
manufacturing  engineer,  but  a design  engineer.  From  the  designing  aspect,  the  house  is  a growing 
awareness,  and  there  always  has  been  a need  for  it.  Keep  in  mind  that  when  we  design  products  we  need  to 
understand  how  they're  going  to  be  manufactured  in  order  to  improve  the  products,  make  them  more 
producible  and  more  affordable.  After  all,  manufacturers  can  only  build  what  a designer  gives  them  to 
build.  Furthermore,  it  can  only  be  as  good  as  it  is  described.  There  is  a tremendous  effort  going  into  to 
trying  to  make  a connection  with  tools  being  developed,  some  of  them  being  internal  to  different 
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companies.  Some  of  the  CAD  systems  are  considering  the  ability  to  embed  or  manufacture  capability  data 
into  databases.  The  purpose  is  for  the  data  to  be  loaded  into  a CAD  database  to  then  flag  the  engineer 
when  they  do  something  wrong.  But,  a significant  amount  of  the  tools  will  not  really  be  available  to  a lot 
of  companies  because  if  they  have  to  go  collect  their  own  process  capability  data.  They  can't  do  it;  they 
may  not  be  as  financially  capable  as  GE's  and  Boeing's  and  some  of  the  larger  companies.  So,  I see  that 
there  is  going  to  be  a need  for  that.  It's  coming  to  the  point  where  you're  not  going  to  be  able  to  compete 
in  designing  products  and  you're  not  going  to  be  able  to  stay  in  business  if  you  don't  understand  how  these 
things  are  going  to  be  manufactured.  That's  one  need  for  that  kind  of  database.  Some  standards  need  to 
be  set  in  order  for  the  developed  tools  to  use  the  established  data. 

MR.  DONMEZ:  If  you  look  at  it  from  the  big  companies'  perspective,  they're  doing  more  and  more 
supplier  certification.  When  Boeing  asks  their  supplier  what  type  of  capacities  they  have,  the  supplier 
might  provide  some  help  to  measure  these  machines,  if  they  don’t  do  it  themselves.  Meanwhile,  the 
funding  issues  would  be  resolved.  Eventually  more  and  more  small  companies  will  provide  that  kind  of 
information  to  large  companies  if  they  want  to  provide  services  to  them. 

MR.  BLOMQUIST:  One  of  the  aspects  of  this  is  mass  characterization  of  machine  tools.  If  it  takes  a 
month  to  characterize  a machine  tool  and  nobody  can  do  it,  there  isn’t  much  value.  However,  a lot  of 
people  are  working  on  fast  characterization  of  machine  tools.  Therefore,  there  is  pressure  to  drive  the  cost 
down.  If  you  believe  that  there  is  going  to  be  a lot  of  out-sourcing,  then  the  small  company  is  going  to  be 
able  to  afford  it. 

MR.  CALLAHAN:  I will  comment  on  that  as  well.  A lot  of  our  service  work  has  started  to  increase  as  a 
result.  It’s  being  driven  by  no  particular  size  company.  We  also  see  it  coming  from  General  Motors  and 
some  other  big  names. 

Before  we  get  away  from  the  web  concept,  I would  like  to  have  a net  site  that  we  could  go  to  and  talk 
about  issues,  exchange  information  and  such.  This  concept  is  based  on  this  set  of  issues  that  we're  talking 
about.  It  would  be  a place,  which  may  be  restricted,  where  we  could  discuss  any  problems  and/or  issues 
related  to  either  the  database  or  data  dictionary. 

MR.  CHANDRASEKHARAN:  With  what  Hans  has  right  now,  we'd  like  to  see  some  way  of  getting 
comments  on  that  and  set  time  lines.  Either  mailing  it  to  us  or  put  it  up  on  the  web  so  we  can  review  it 
independently  by  a certain  date. 

MR.  DONMEZ:  As  an  action  item,  we  should  establish  a web  site  for  everyone  to  have  access  to  as  well 
as  be  able  to  put  their  comments  on.  We  will  also  put  the  documents  that  we  are  distributing  here  today  on 
the  web  site.  The  documents  will  take  a little  more  time  because  they  all  have  to  go  through  an  approval 
process,  but  the  web  site  itself,  I'm  assuming,  can  be  approved  shortly. 

MR.  CHANDRASEKHARAN:  It  doesn't  have  to  be  the  web.  It  could  start  off  by  just  routing  documents. 
We'd  like  to  get  some  of  what  Hans  has.  I fully  endorse  what  Professor  Patterson  said.  Let’s  try  to  take  it 
to  the  next  level;  not  just  looking  at  the  ballbar,  but  start  looking  at  the  other  devices  too.  Let’s  try  and 
consolidate  on  the  data  definitions  and  start  moving  in  order  to  set  a schedule.  Maybe  we  could  initiate 
something  within  the  group  to  speed  up  some  of  these  ideas  and  move  from  the  ballbar  to  a full 
characterization  of  a machine.  Hopefully,  we’ll  have  solved  these  problems  by  our  next  meeting. 
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MR.  SOONS:  I would  just  like  to  reiterate  the  status  of  the  formatting  issue.  What  we  currently  have,  and 
what  I've  tried  to  write  down,  is  basically  a lot  of  ideas  about  what  such  a format  could  look  like.  It  is 
definitely  not  the  final  choice,  but  it  cannot  be  left  at  this  stage.  But  one  thing  I would  like  input  on  is 
what  our  next  move  should  be  from  that  point.  Should  we  formalize  it  into  a strawman  model  so  people 
can  review  it  or  should  we  have  some  collaborative  effort  in  progress?  What  is  our  next  move? 

MR.  CHANDRASEKHARAN:  Get  started.  You've  got  enough  for  a strawman.  Just  table  that  and  we'll 
respond.  We've  got  plenty  in  here. 

MR.  ZIEGERT:  I was  going  to  suggest  some  reasonable  metrics  to  measure  the  completeness  of  the  data 
format  as  the  first  step.  There  has  to  be  enough  information  there,  that  a person  could  go  in  and  recreate 
the  exact  test  that  developed  the  data  and  presumably  get  the  same  data.  Keeping  in  mind  the  eventual 
goal  of  virtual  manufacturing,  there  should  also  probably  be  enough  data  for  it  to  then  be  used  in  the 
machine  models  and  in  the  virtual  model.  Those  might  be  reasonable  metrics  against  which  to  judge  what 
needs  to  be  there  and  what  doesn't  need  to  be  there. 

MR.  CHANDRASEKHARAN:  I think  we  also  need  to  focus  on  where  this  fits  in  the  hierarchical  nature 
of  the  final  database  that  we're  talking  about  with  physical  descriptions  and  such.  I don't  know  if  you  want 
to  put  some  thoughts  together  on  that;  merging  what  you  have  in  performance  with  what  you  had  in  the 
previous  definitions  as  to  where  you  see  the  performance  metrics  going.  Is  that  going  to  be  inclusive,  or 
are  you  still  going  to  keep  them  independent  like  this? 

MR.  SOONS:  If  I were  to  continue  with  this,  I would  probably  take  that  second  document  on  performance 
evaluation  and  start  working  that  one  out,  because  that  can  be  reasonably  self-contained,  and  start  with  the 
general  machine  data  on  there. 

MR.  DONMEZ:  I think  we  have  to  keep  in  mind  that  whatever  we  end  up  with  will  have  some  layered 
structure,  starting  from  very  raw  data  all  the  way  through.  There  may  be  a few  numbers  of  information 
about  the  machine.  Depending  on  the  need,  you  can  go  in  different  layers:  (1)  to  either  duplicate  the 
information,  (2)  use  the  information  in  the  models  to  create  the  simulation  or  (3)  compare  a few  numbers 
from  Machine  A to  Machine  B. 

MR.  CALLAGHAN:  The  people  here  are  used  to  looking  at  all  these  charts,  analyzing  them  and 
understanding  what  they  mean.  In  my  world,  I have  to  translate  all  that  into  something,  simple  and 
concise  enough  for  a manager  to  look  at  and  help  him  make  decisions.  A lot  of  what  I was  commenting  on 
to  Steve  earlier,  is  probably  of  interest  to  only  half  a percent  of  the  people  at  my  company.  I have  to  figure 
out  a way  to  bring  that  to  a much  higher  level  and  make  sense  out  of  it  at  a machine  shop  management 
level,  so  they  can  make  decisions.  We  need  to  synthesize  all  of  this  ground-level  data  into  something  for 
them  to  make  decisions  at  a high  level.  We  can  keep  the  low  level  information,  but  we  don't  want  to  lose 
sight  of  who  a lot  of  our  end-users  will  be. 

MS.  McMILLAN:  Can  we  start  a formal  data  dictionary  in  which  we  can  have  input?  Then  at  the  next 
meeting  maybe  we  can  review  that  list  and  get  started? 

MR.  WELSCH:  I think  we  will  put  that  out  on  the  web  site  as  well. 

MR.  DEFORGE:  As  a virtual  manufacturing  modeler  who  does  this  for  a living,  I find  the  information  in 
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the  sub-notes  on  the  machine  tool  data  base  document,  appear  to  be  of  more  value  to  me  than  what  we 
spent  a great  deal  of  time  talking  about  today.  As  far  as  working  with  these  types  of  measurements,  I 
understand  the  value.  Don't  get  me  wrong.  I understand  how  important  they  are  to  an  individual  company 
and  to  bridging  that  gap  between  virtual  reality  and  calibrating  your  virtual  environment  to  what's  actually 
taking  place  down  on  the  factory  floor.  From  my  perspective.  I'd  rather  see  some  more  work  go  into  these 
definitions  as  to  what  we  need  to  create  virtual  machines.  What  kind  of  information  do  we  need,  as 
modelers,  to  rapidly  build  a machine  tool  in  a virtual  environment  that  will  give  you  a tool  for  bridging  the 
gap  between  design  and  manufacturing? 

If  I have  to  hunt  all  over  the  country  for  information  on  how  the  axes  of  this  particular  machine  tool  are 
supposed  to  operate,  which  controller  they  marry  up  with,  and  what  features  we  actually  took  advantage  of 
for  this  machine  tool,  that  becomes  a month  long  process  in  building  a virtual  machine  tool;  not 
necessarily  taking  a look  at  these  measurements  and  calibrating  my  virtual  environment  to  the  real 
environment.  It  is  sometimes  very  difficult  to  gather  some  of  this  information.  The  machine  tool  builders 
aren't  walking  up  to  us  and  saying,  "Here  is  everything  you  need."  I'm  wondering  if  we're  backing  into 
this  when  we  should  be  approaching  from  a higher  level. 

MR.  CHANDRA SEKHARAN : That's  part  of  what  I had  in  my  slides  too.  Are  we  enabling  everything 
that's  happening  today?  Are  we  supporting  the  current  database  that's  out  there,  the  current  simulation 
tools,  with  what  we're  developing,  or  are  we  getting  to  a level  of  detail  that  is  far  beyond?  I think  if  we 
can  generate  a model  out  of  the  data  structure  that  we're  developing,  can  we  give  it  enough  information  to 
get  an  accurate  cycle  time  analysis,  and/or  an  accurate  collision  check  analysis?  That's  what  virtual 
manufacturing  is  for  us  today,  though  it's  not  down  to  the  level  of  detail  where  we  want  to  be  five  years 
from  now.  Given  the  data  definitions  that  we  have,  can  we  do  that  any  better? 

MR.  DONMEZ:  As  a matter  of  fact,  that's  exactly  why  we  put  the  discussion  on  simulation  tools  as  our 
priority  tomorrow.  I think  we  should  address  those  needs  and  requirements.  For  those  simulation  tools: 
what  type  of  data,  what  type  of  information  do  we  need  for  them  to  simulate  realistically,  and  not  in 
nominal  terms? 

MR.  ESTERLING:  If  what  you  were  even  providing  us  either  parametrically  defined  error  functions  or  a 
look-up  table,  all  of  those  are  just  perturbations  of  what  we've  been  doing  already  in  terms  of  modeling.  I 
don't  think  the  format  matters  that  much.  I think  if  the  information  is  complete  and  clearly  defined  we  can 
proceed  without  any  problem.  If  it's  not  complete,  then  we  simply  assume  there  are  no  errors  in  that 
particular  type  of  degree  of  freedom  and  continue. 

MR.  DONMEZ:  You're  saying  the  information  that  is  provided  is  incomplete.  Well,  we'd  like  to  find  out 
what  type  of  information,  and  in  what  form  we  should  provide  it  for  a package  like  yours  and  Deneb's,  and 
how  that  package  would  utilize  that  information. 

MR.  ESTERLING:  Our  package  accepts  where  the  machine  tool  is  going,  and  currently  it  accepts  it  on 
block-by-block  code.  Now,  if  you  start  having  errors  in  there,  all  of  a sudden  a long  tool  move  might  be 
broken  down  into  smaller  steps,  but  we  just  need  to  know  where  the  tool  is  going.  Then  we  can  go  off  and 
cut.  If  there  is  an  error  function,  some  perturbation  to  be  imposed  on  that,  that's  what  we  can  do. 

MR.  DONMEZ:  But  what  we'd  like  to  do  is  have  a generic  way  of  interfacing  with  packages  like  yours. 
You  can  do  it  for  your  own  package,  but  it  may  not  be  generic.  I don't  know  if  Deneb  can  do  it  the  same 
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way,  or  in  any  other  way,  as  long  as  we  provide  that  generic  information. 

MR.  ZIEGERT:  In  looking  at  the  information  that's  on  this  particular  form  here.  I'd  say  approximately  85 
percent  of  that  is  information  that  I need  to  make  an  accurate  representation  of  both  the  kinematics  and  all 
the  peripheral  devices  and  everything  else  that's  involved  in  a particular  machine  center.  It's  very  valuable 
information.  I mean,  I'd  love  to  be  able  to  go  to  the  web  and  make  a few  clicks  like  we  saw  here  today  and 
get  all  the  information  that  I needed  to  put  together  a machine  tool  to  marry  up  this  machine  tool,  in  this 
configuration,  with  this  particular  controller,  and  be  able  to  walk  out  in  a couple  of  days  with  a model  to  be 
able  to  hand  Boeing,  GE,  General  Motors,  or  anybody  else.  I don't  want  this  to  be  lost. 

MR.  DONMEZ:  What  we'd  like  to  see  is  not  a couple  of  days,  but  maybe  a couple  of  hours. 

REFERENCES 

1.  (Reference  to  Simon  Frechette’s  presentation  in  this  document). 

2.  Wilson,  P.R.  Express  Tools  and  Services.  Working  Manuscript.  NIST.  Gaithersburg,  Maryland.  1995. 

3.  Massachusetts  Institute  of  Technology,  Laboratory  for  Computer  Science.  The  World  Wide  Web 
Consortium.  The  Consortium.  Cambridge,  MA.  [computer  file]  http://www.w3.org/. 

4.  Werbach,  K.  The  Barebones  guide  to  HTML,  [computer  file] 
http://werbach.com/barebones/barebone.html. 

5.  Microsoft  Corporation.  Microsoft  Win32  Programmer’s  Reference.  Microsoft  Press,  One  Microsoft 
Way,  Redmond,  Washington.  1993. 

6.  The  Math  Works,  Inc.  Using  MATLAB.  The  MathWorks,  Inc.  24  Prime  Park  Way,  Natick,  MA. 
December  1996. 

7.  Adobe  Systems  Incorporated.  PostScript  Language  Reference  Manual.  Addison-Wesley  Publishing 
Company,  Reading,  MA.  1990. 

8.  Wall,  L.,  Christiansen,  T.  & Schwartz,  R.  Programming  Perl.  O’Reilly  & Associates,  Inc.,  Sebastopol, 
CA.  1996. 

9.  Bolsky,  M.  I.  & Korn,  D.G.  The  KomShell  Command  and  Programming  Language.  Prentice  Hall, 
Englewood  Cliffs,  N.J.  1989. 

10.  Mortice  Kern  Systems  Inc.  MKS  Toolkit  Reference  Manual.  Mortice  Kern  Systems  Inc.  Waterloo, 
Ontario,  Canada.  1995. 

11.  Simpson,  A.  Netscape  Navigator  Gold  3.0  Book.  Ventana  Communications  Group,  Inc.  Research 
Triangle  Park,  NC.  1996. 


-91- 


DISCUSSIONS  ON  NEEDS  AND  REQUIREMENTS  FOR 
INTERIM  MACHINE  PERFORMANCE  DATA 


MR.  DONMEZ:  I have  asked  Loyd  Bishop  to  give  us  some  directions  on  the  interim  checks  because  he 
has  done  quite  a bit  of  work  on  them.  We  need  to  discuss  what  the  optimum  amount  of  data  is  that  will  be 
useful  for  periodic  machine  checking. 

MR.  BISHOP:  In  the  last  workshop,  I pointed  out  that  we  have  a lot  of  probing  data  sets  from  our  tower 
artifact.  But  it's  an  application-specific  test  for  this  machine  that  we've  had  notorious  problems  with  in 
terms  of  the  B and  C axes.  As  we  accept  parts  from  machine  tool  probing  data,  we  want  to  evaluate  our 
machine  tools  as  measuring  machines.  So,  for  interim  checks,  if  they're  bridge-type  machines  or  if  they're 
vertical  spindle-type  machines.  I'd  like  to  encourage  the  use  of  the  NIST  interim  test  artifact  developed  for 
Coordinate  Measuring  Machines. 

With  horizontal  machining  centers,  we're  asking  the  machine  to  go  out  and  perform  a duty  cycle  on  some 
specific  parts  that  we've  got  and  then  drive  that  pallet  out,  bring  a dedicated  pallet  with  the  step  gauge,  and 
measure  linear  displacement  errors  along  X and  then  along  Y directions.  Since  this  is  a horizontal  spindle 
we're  going  to  tilt  the  step  gauge  45  degrees  and  measure  it  as  a combination  of  Y and  Z.  And  then  I want 
to  turn  it  45  degrees  so  I can  get  one  body  diagonal  and  then  90  degrees  back  the  other  direction.  And  get 
another  body  diagonal,  so  I can  evaluate  that  machining  center  as  a measuring  machine.  So,  those  are  the 
kinds  of  interim  checks  I'd  like  to  see  run.  And  I think  they  would  be  quite  meaningful  to  us. 

MR.  CALLAHAN:  How  long  will  they  take,  Loyd? 

MR.  BISHOP:  We're  not  sure  yet.  We're  still  working  on  that  because  the  controllers  aren't  very  friendly. 
They  don't  work  the  same  as  coordinate  measuring  machines  do.  With  our  specific  integrated  probing 
system,  they're  telling  me  there  is  an  offset,  but  it  will  be  an  equal  offset  each  time  when  they  rotate  the 
pallet.  So  I really  don't  know.  We're  just  scratching  the  surface  on  this  right  now.  We  have  run  the  NIST 
interim  test  artifact  on  some  machine  tools  but  not  with  much  success  due  to  the  amount  of  probing. 
Triggering  pressure  is  like  65  grams  on  the  machine  tool  probes,  so  we  think  the  balls  were  actually  being 
twitched  out  of  the  kinematic  mouse.  I received  some  new  brackets  that  have  stronger  magnets.  We're 
going  to  try  that  and  see  if  we  have  some  success  with  it. 

MR.  DONMEZ:  How  often  do  you  foresee  the  need  to  carry  out  these  interim  checks? 

MR.  BISHOP:  That's  a good  question.  I'd  like  to  abandon  this  tower  check  we  have  because  it's  really  just 
a check  for  a specific  part.  It  does  a lot  of  things.  It  tells  us  the  health  of  the  B and  C axes.  We  started 
doing  this  test  because  we  have  very  expensive  parts  to  make  and  we  wanted  to  make  sure  that  the 
machine  was  functioning  properly  before  we  went  out  and  scrapped  one  of  those  very  expensive  parts. 
We've  got  approximately  1,300  or  1,400  datasets,  just  as  a six  minute  quick  check  to  determine  if  there  is  a 
problem  with  the  B and  C axes  and  also  to  create  our  tool  point  compensation  files.  That  has  been 
approved  through  our  Legal  and  Public  Relations  Department,  so  I can  get  you  a copy  of  that. 

MR.  CALLAGHAN:  Loyd,  how  much  of  the  work  envelope  does  that  cover? 

MR.  BISHOP:  Not  very  much,  and  that's  a real  concern  as  well.  But  NIST  is  supposed  to  be  making  the 
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bigger  brackets  for  the  900  and  1,500  mm  ballbar.  We  would  like  to  use  an  artifact  that's  pretty  much  a 
replica  of  the  3D  volume  part  that  we've  got  but  in  some  cases  we  can't  always  do  that.  So  we  try  to  use 
the  largest  thing  we  have,  then  we  look  at  the  laser  diagonal  displacement  errors  and  we  make  some 
assumptions  about  how  the  machine  would  measure  throughout  that  big  volume.  But,  they're  not  always 
good  assumptions. 

MR.  CHANDRASEKHARAN:  Depending  on  the  parts  that  you're  machining,  you  might  want  to  check 
only  a few  characteristics  instead  of  characterizing  the  entire  machine,  as  opposed  to  trying  to  build 
ambient  models,  so  you  have  different  uses  for  it.  We  don't  have  a clear  picture  of  all  the  interim  checks 
we  have  to  measure,  but  I think,  from  a virtual  manufacturing  standpoint,  that  is  an  issue  that  came  up,  but, 
we  haven't  given  it  extensive  thought.  I don't  have  too  much  data  on  it  to  share  at  this  point,  but  we 
certainly  can  look  into  it  some  more  and  get  back  to  you  about  it. 

MR.  DONMEZ:  What  do  you  think,  as  far  as  the  company's  perspective,  is  an  affordable  amount  of  tests 
that  you  want  to  carry  out  periodically? 

MR.  CHANDRASEKHARAN:  We  would  like  to  see  the  ballbar  done  once  every  month  on  our  machine- 
-that's  what  we're  trying  to  recommend  to  our  plants— and  a full  characterization  definitely  after  any  major 
breakdown.  As  we  start  building  models,  we  may  be  carrying  them  out  once  every  six  months  in  the 
summer  and  winter  times,  after  that,  it  might  be  periodically  every  year.  But  we  haven't  gone  into  that 
level  of  detail  of  putting  together  a strategy.  Again,  it  depends  on  how  quickly  we  can  measure  these 
errors.  We're  starting  to  use  ballbars  on  a more  periodic  basis,  but  full  characterization  of  the  machine 
depends  on  the  success  of  the  projects  we  have  on  rapid  error  assessments. 

MR.  ZIEGERT:  It  strikes  me,  from  Loyd's  description  of  what  they'd  like  to  do  for  interim  performance 
checks  on  probing  step  gauges  and  various  orientations,  that  the  kind  of  data  you  would  generate  there 
would  be  a real  challenge  to  incorporate  in  the  data  structure  that  we've  put  up  here  so  far.  The  implicit 
data  structure  that  Hans  has  put  up  here  kind  of  follows  the  classical  notion  of  machine  metrology  of  21 
errors  or  6 degrees  of  freedom  per  axis,  and  axis  alignments.  It's  not  immediately  clear  to  me  how 
machine  performance,  as  a measuring  machine,  over  some  arbitrary  artifact  in  some  arbitrary  orientation  is 
going  to  be  characterized  successfully  in  this  database.  I think  that  might  be  a real  challenge. 

MR.  SOONS:  I think,  once  you  start  using  the  machine  as  a measuring  machine  and  you  use  artifacts,  and 
probe  them,  you  should  use  the  appropriate  standard— in  this  case  it  would  be  a Dimensional  Measurement 
Inspection  Specification  (DMIS)  format,  or  something  like  that— to  describe  it.  I don't  think  we  should  try 
to  replicate  DMIS  within  a format  like  this. 

MR.  DONMEZ:  But  I'm  not  even  sure  if  DMIS  really  covers  that  capability  issue. 

MR.  SOONS:  It  describes  basically  all  the  things  that  a coordinate  measuring  machine  can  do.  I think  it 
comes  close  to  the  application  that  was  being  described  here. 

MR.  ZIEGERT:  Of  course  there  aren't  any  CMMs  with  A,  B,  and  C axes  on  them,  at  least  not  very  many. 

MR.  DONMEZ:  It  would  probably  be  more  related  to  the  B89  standard  than  DMIS,  because  you  are  using 
the  machine  as  a CMM  and  then  you  have  to  follow  the  B89  definitions  of  performance. 
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MR.  CHANDRA SEKHARAN:  What  if  the  metrics  you  measure  from  the  artifact  are  converted  back  to 
any  of  the  other  high  level  metrics  like  squareness  and  displacement,  errors  like  that,  so  if  you  get  to  that 
level  of  definition  and  extract  those  parameters  out  of  the  artifact  you  can  still  populate  and  update  those 
fields. 

MR.  DONMEZ:  For  some  of  the  features,  yes,  you  can  do  that,  but  some  of  them  will  be  real 
complicated. 

MR.  CHANDRASEKHARAN:  Right.  Raw  data  is  going  to  be  a different  issue. 

MR.  SOONS:  What  we  could  think  of  is  a data  file  that  basically  contains  your  usual  header  information, 
in  this  case  where  the  artifact  is  and  what  you  want  to  do,  and  then  it  simply  contains  in  this  one  full  block 
the  whole  DMIS  measurement  file,  or  whatever  the  format  might  be,  and  then  I think  on  the  level  higher 
that  will  really  depend  on  what  you  want  to  do.  I think  it's  difficult  at  this  point  to  take  that  into  account, 
what  you  want  to  do  with  the  data. 

MR.  CALLAHAN:  But  how  different  is  it  really  from  laser  data?  You  take  a step  gauge  and  you  measure 
it  with  a Renishaw  probe  and  in  the  description  of  the  data  you  just  say,  "we  used  this  instrument,  which  is 
the  machine  tool  scale,  and  the  Renishaw  probe,  and  we  used  this  artifact  and  it's  aligned  along  a certain 
vector  in  the  machine." 

MR.  SOONS:  It's  going  to  be  difficult  because  once  you  start  measuring  artifacts  you  will  have  a whole 
host  of  new  things,  like  feature  definitions  and  you’ll  have  to  start  defining  spheres  and  circles  and  all 
those  kind  of  things.  I think  it's  a different  kind  of  thing.  In  my  opinion,  DMIS  is  an  excellent  standard  to 
handle  that  kind  of  thing  because  it  was  built  for  that  purpose. 

MR.  DONMEZ:  Yes.  If  you  have  a one-dimensional  measurement  like  you  described  by  the  step  gauge, 
it  may  be  easy  to  correlate  step  gauge  to  laser,  but  if  you  have  a two  or  three-dimensional  measurement, 
like  an  artifact,  cylindricity,  or  squareness,  and  all  these  things,  then  you  might  encounter  a problem  of 
correlating  that  with  the  laser  data. 

MR.  CALLAHAN:  Yes,  but  shouldn't  the  interim  check  just  be  a subset  of  that  information?  If  you're 
properly  designing  the  artifact,  it  should  really  be  a subset  of  what  you're  getting. 

MR.  BISHOP:  The  NIST  interim  test  artifact  should  reveal  the  errors  that  you  see  when  you  run  the 
parametric  error  measurements. 

MR.  DONMEZ:  But  not  that  tower  test  that  you  were  talking  about? 

MR.  BISHOP:  No,  not  the  tower  test  and  not  the  step  gauge.  When  we  use  the  NIST  interim  test  artifact 
on  the  bridge-type  machines  then  we  should  be  seeing  what  we're  seeing  when  we  perform  the  parametric 
tests. 

MR.  CALLAHAN:  I don't  think  it's  that  difficult  to  design  the  interim  artifact  so  it's  very  similar  to  the 
more  complete  test. 

MR.  SOONS:  I think  it  would  be  not—  I think  you're  right  on  simple  artifacts,  like  the  NIST  artifact. 
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which  is  basically  two  spheres,  but  should  you  then  think  about  more  complicated  artifacts?  Now  where 
are  we  going  to  set  the  limit? 

MR.  CALLAHAN:  What  did  Zeiss  do  with  their  three-dimensional  artifact?  They  had  a couple  of  them. 
They  had  a plate  artifact  and  they  also  had  one  which  was  a cute  kind  of  geodesic  thing  following  stuff  all 
over  in  space. 

MR.  SOONS:  I think  it  might  be  possible  to  perhaps  take  some  nice  things  from  DMIS  and  incorporate  it 
into  the  standard. 

MR.  CHANDRA SEKHARAN:  Maybe  this  would  be  a means  for  people  to  get  their  artifact  certified,  if 
they  come  up  with  something,  whether  it  matches  the  data  fields  that  you've  assigned  for  the  parametric 
errors?  Is  it  a subset  of  it,  or  a combination  that  they're  measuring  by  artifact? 

The  other  issue  is  that  it  may  not  be  an  interim  measurement  of  these  errors,  but  the  data  we  collect  from 
the  factory  process  capability  information.  I don't  know  where  you  would  classify  that,  whether  that's 
interim  data  or  it's  just  company-specific  data,  but  that  is  data  that  we  definitely  plan  on  collecting 
periodically  and  tracking  and  that  gives  a good  indicator  of  performance. 

MR.  DONMEZ:  But  that  test  you're  talking  about  includes  cutting  tests,  right? 

MR.  CHANDRA  SEKHARAN:  Yes.  Capability  of  features  and  metrics  that  we're  measuring. 

MR.  DONMEZ:  We  have  a classification  as  "Cutting  Tests,"  and  that  type  of  information  would  go  into 
it. 

MR.  CALLAHAN:  On  your  interim  test  data,  can't  you  handle  it  exactly  the  same  as  you  handle  your 
hardware  reporting?  I have  no  difficulty  at  all  with  my  interim  part.  I've  got  my  squareness  of  the 
machine,  alignments,  cross-over  errors,  thermal  distortions,  and  it  gets  passed  up  with  the  reporting  of  the 
hardware  dimension.  I already  have  that  in  my  DNC  system  and  can  pull  it  down  and  chart  it. 

MR.  CHANDRA  SEKHARAN:  Are  you  talking  about  artifacts,  interim  measurements  or  complete 
parametric  characterizations? 

MR.  CALLAHAN:  Not  the  complete.  The  complete  is  the  one  I had  difficulty  with.  The  artifact,  and 
most  of  the  times  the  artifact  is  my  actual  hardware,  to  determine  my  machine  squareness,  cross-over 
errors,  so  that  I have  no  difficulty  in  communicating.  It's  only  when  I go  into  non-workpiece,  or  non- 
hardware that  I have  a difficulty  in  communicating  it. 

MR.  CHANDRASEKHARAN:  But  do  we  have  assigned  fields  in  the  structure  that  is  being  defined  was 
how  the  question  started  out? 

MR.  CALLAHAN:  No. 

MR.  CHANDRASEKHARAN:  That's  how  we  started  the  whole  issue,  whether  we  have  room  in  the 
database,  as  it  is  designed  right  now,  or  as  we  are  planning  on  going  with  it,  to  accommodate  data  of  this 
sort,  because  it's  very  useful  data.  Just  like  you  said,  you  can  plot  it  out  and  you  can  keep  track  of  it,  but 
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will  the  database  that  we're  proposing  support  it? 

MR.  CALLAGHAN:  Now  what  you're  saying  there,  Dave,  is  you  are  uploading  this  information  coming 
from  the  machine  tool  through  your  DNC  link,  whereas  the  characterization  data  is  coming  from  a 
different  source? 

MR.  CALLAHAN:  Yes. 

MR.  SOONS:  Just  to  go  back,  I think  it's  an  important  distinction  that  is  being  made.  If  we  are  talking 
about  artifacts  which  are  specifically  designed  for  testing  like  a straightedge  and  a square  block,  and 
perhaps  even  things  like  a step  gauge,  it  is  relatively  easy  to  handle  them  in  a format  like  we  were 
discussing.  However,  once  you  start  talking  about  artifacts  that  resemble  the  part  that  you  want  to 
manufacture  and  you're  going  to  probe  that  artifact  on  your  machine,  then  I think  it's  better  to  rely  on 
formats  that  were  specifically  designed  for  that  purpose  like  DMIS. 

MR.  CALLAHAN:  Hans,  in  your  specification  here,  you  have  basically  raw  data  and  then  various  higher 
level  analysis.  Is  the  goal  to  provide  a lot  of  raw  data  into  the  repository.  Is  somebody  going  to  try  to 
consolidate  this  in  some  sense  and  parameterize  it,  or  is  it  just  going  to  sit  there  in  raw  data  form? 

MR.  DONMEZ:  I think  the  idea  is,  if  the  data  is  well  defined,  anybody  can  start  doing  the 
parameterization.  UNCC  should  be  able  to  take  that  data  and  start  parameterizing  it,  or  Caterpillar  should 
take  that  data  for  parameterizing,  and  we  will  do  the  parameterization  because  we  are  interesting  in 
modeling  those  machines.  So,  as  long  as  data  is  unambiguous  and  is  well  defined,  then  I think  we  can  get 
there. 

QUESTION:  Can  we  back  up  to  the  interim  test  artifact  for  just  one  moment?  I plead  ignorance  in  the 
whole  machine  characterization.  I've  never  been  involved  with  it  and  this  is  probably  my  first  experience, 
even  with  much  of  the  terminology.  But  I have  worked  in  the  characterization  of  CMMs  and,  in  fact,  I 
helped  develop  the  interim  testing  artifact.  I believe  what  I heard  was  that  we  were  able  to,  through  using 
the  interim  test  artifact,  look  at  the  characterization  and  determine  the  error  parameters  of  a coded 
measuring  machine.  Well,  the  interim  testing  artifact  actually  doesn't  have  that  flexibility.  Actually  we 
identified  with  CMMs  three  primary  sources  of  error,  and  that  is  3 errors  in  terms  of  geometrical  sources 
of  error,  which  this  is  designed  to  check.  One  is  the  squareness.  Another  source  of  error  is  the  ability  of 
the  machine  probe,  or  the  measurement  probe,  to  lock  up  in  a unique  position  and  each  and  every  time  it 
repeats  that  position.  So  when  we  measure  the  ballbar  and  we  look  at  the  form  error  of  each  bar  and  we 
use  a different  index  probe.  So,  if  we  see  that  a form  is  bad  and  we  used  a different  index  probe  we  know 
that  we  may  have  a problem  in  the  repeatability  of  our  lock-up.  So  we're  not  actually  looking  at  the 
characterization  of  a CMM  during  the  measuring;  we're  actually  trying  to  delineate  the  source  of  error.  So 
it  may  not  be  the  kind  of  information  you  want  to  include  because  it's  very  specific.  It  gives  you  no  real 
information  about  the  error  itself,  but  just  a kind  of  general  information  that  you  can  run  the  machine  so 
when  your  technician  comes  in  he  can  say,  "I  seem  to  be  having  a problem  with  my  probe  indexing," 
instead  of  "I  have  a problem;  fix  it."  So,  I think  maybe  they  were  misunderstood  that  we  might  be  able  to 
get  more  out  of  the  interim  testing  artifact  than  we  actually  are. 

MR.  BISHOP:  It's  a nice  baseline  tool  also. 

QUESTION:  Yes.  Absolutely. 
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MR.  BISHOP:  Just  like  running  the  telescoping  ballbar,  if  you  look  at  degradation  of  the  machine  tool 
over  time  it's  an  excellent  tool  for  that,  so  there  is  a lot  of  things  you  can  deduct  from  the  NIST  interim  test 
artifact,  and  one  of  them  also  being  linear  accuracy.  I mean  you  can  definitely  look  at  linear  accuracy. 

MR.  CALLAGHAN:  Hans,  have  you  started  a data  dictionary  yet? 

MR.  SOONS:  No.  That  will  be  the  next  step,  to  build  a strawman  document  on  that  one  and  then 
distribute  it. 

MR.  DONMEZ:  Do  you  have  any  dictionary  at  all  at  Boeing? 

MS.  McMILLAN:  We  have  a validated  dictionary  on  other  stuff,  but  not  on  this.  But  we  do  have  the 
beginning  of  one,  yes,  because  of  our  data  modeling  stuff,  not  that  I could  tell  you  anything  about  it,  but 
we  are  beginning. 

MR.  BISHOP:  But  we  are  going  to  check  to  see  if  we  can  tell  you  and  still  maintain  it  at  a proprietary 
level. 

MR.  SOONS:  That's  an  action  item  for  the  next  meeting? 

MR.  BISHOP:  Sure. 

MS.  McMILLAN:  Sure.  I'll  take  that  as  an  action  item. 

MR.  MA:  If  you  have  two  data  sets  from  the  same  machine  in  your  database,  how  will  you  treat  them,  just 
based  on  the  time  you  saved  them?  Like  where  you  put  in  one  set  of  data  and  then  you  get  another  set  of 
data  they  send  to  you,  the  same  machine,  the  same  measurement,  just  different  date. 

MR.  SOONS:  Probably  the  date. 

MR.  MA:  The  other  thing  is  how  long  you  would  keep  the  data  for  a certain  machine?  Is  it  one  year  or 
two  years,  or  whatever? 

MR.  SOONS:  I think  that  very  much  depends  on  the  users.  Some  people  will  want  to  keep  it  forever. 

MR.  MA:  So,  the  user  will  give  you  a code  saying,  "I  want  this  one  to  be  kept  for  a while,"  or  you  haven't 
thought  of  that? 

MR.  SOONS:  I don't  think  that  would  be  a hard  task  at  all. 

MR.  CALLAGHAN:  I think  typically  we'd  like  to  keep  it  all  because  when  we  get  a brand  new  machine 
in  I want  to  see  what  is  right  then  and  there  and  see  what  the  degradation  is  over  time,  and  when  they 
retrofit  it,  I want  to  go  back  and  compare  this  retrofit  information  back  to  the  original  and  see  if  we  can 
improve  it. 

MR.  MA:  So  do  you  archive  them  to  a floppy  disk? 
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MR.  CALLAGHAN:  I back-up  on  floppy,  as  well  as  on  the  hard  drive,  and  we're  looking  at  a system  for 
porting  that  into  a Unix  database  that  we've  been  talking  about,  and  actually  we're  working  on  an  Access 
database  to  parallel  it,  so  we've  kind  of  got  quite  a bit  of  action  going  on  there. 

MR.  MA:  Do  you  back  up  all  the  machines  at  once,  or  do  you  back  it  up  machine-by-machine? 

MR.  CALLAGHAN:  Right  now,  we  are  doing  through  the  method  that  each  machine  has  got  a 
subdirectory,  which  is  a somewhat  painful  way  to  do  it,  and  we  index  the  file  name  and  increment  the  file 
name  each  time.  So  you  get  a date  stamp  and  an  X-Y  axis  test  and  then  date  stamp  and  a Y-Z  axis  test, 
and  we  keep  it  in  the  order  you  do  the  testing.  It's  kind  of  a clumsy  way  of  doing  it,  that's  why  we  want  to 
use  the  databases. 

MR.  DONMEZ:  One  of  the  things  that  I pointed  out  in  the  morning  as  part  of  the  discussions  in  the  last 
workshop  is  to  identify  as  well  as  weed  out  the  bad  data,  and  I think  that's  going  to  be  a very  difficult 
issue.  Does  anybody  have  any  ideas  on  that? 

MR.  BISHOP:  I don't  think  we  need  to,  Alkan.  I think  the  majority  of  the  data  is  going  to  be  good  data 
and  it's  going  to  average  out  over  the  long  run.  I've  been  thinking  a lot  about  what  Steve  said  at  the  last 
meeting  and  I agree  with  what  he  said,  but  the  majority  of  the  data  that  we  put  into  this  should  be  good 
data. 

MS.  McMILLAN:  And,  if  you  do  have  something  that's  really  odd,  there  are  ways  of  highlighting  that 
and  commenting. 

MR.  CALLAGHAN:  One  of  the  easiest  ways  we  do  that  is  to  look  at  the  history.  If  it  doesn't  match  the 
history,  and  I immediately  run  the  test  and  I say,  "Hey,  here  is  what  it's  supposed  to  look  like;  why  is  it  so 
far  off?"  The  first  thing  I do  is  to  check  the  setup.  Setup  is  95  percent  of  the  primary  problem.  And  they 
may  go  back  and  find  something  loose,  or  something  wrong  with  a fixture.  So,  I think  the  biggest  check 
we've  got  is  history.  If  it's  not  within  certain  bandwidths  of  the  previous  performance  then  a flag  goes  up. 

MR.  HEMERLE:  When  you  do  your  measurement  for  linear  positioning  accuracy  using  laser 
interferometer,  do  you  measure  on  even  grids  to  determine  your  cyclic  error,  or  do  you  split  the  cyclic 
error  two  times  over  the  run?  How  do  you  handle  cyclic  error?  That's  what  I call  bad  data.  The  guy  has 
measured  the  machine,  didn't  tell  me  what  the  grid  spacing  was  and  therefore  I've  included  my  cyclic  error 
in  there. 

MR.  DONMEZ:  But  B5  recommends  that  you  include  that  into  your  data.  In  other  words,  if  you  have  a 
metric  machine,  you  measure  it  in  English  so  that  you  don't  separate  the  cyclic  errors. 

MR.  CALLAHAN:  To  determine  the  manufacturing  capability  of  the  machine  that's  okay,  but  you 
wouldn't  want  to  do  that  for  your  compensation  evaluation  tests. 

MR.  DONMEZ:  Right.  If  you  want  to  know  the  periodicity,  then  you  have  to  use  different  ways. 

MR.  CALLAHAN:  When  you  have  your  data  put  in,  you  would  need  to  know  that,  would  you  not? 
Otherwise,  I would  say  I don't  know  whether  that's  good  data  or  bad  data. 
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MR.  DONMEZ:  Right. 


MR.  CALLAHAN:  But,  again,  that's  just  another  piece  of  information  about  the  machine  performance, 
like  periodic  errors,  just  like  bolt  error  effect  on  squareness.  The  periodic  error  affects  your  accuracy,  so 
you  have  to  have  that  information  so  you  really  know  what  the  overall  performance  of  the  machine  is. 

MR.  CALLAGHAN:  Yes,  but  what  I'm  looking  at,  if  I sent  you  one  set  of  data  and  said,  "Here  I measured 
a machine  and  here  I measured  a machine,"  if  one  of  those  I have  done  on  the  grid,  I'm  showing  you  the 
accuracy,  and  if  another  one  I split  it  so  I see  the  sine  error  four  times  in  it.  If  all  you're  seeing  is  my 
results,  you  won't  know  what  the  source  of  the  difference  is. 

MR.  BISHOP:  The  standard  tells  us  to  not  measure  it  as  we  compensate  it  when  we  evaluate  it. 

MR.  CALLAHAN:  It  also  tells  you  to  run  periodic  error.  So  you'd  have  to  see  both.  I would  never  report 
squareness  without  reporting  all  the  pitch  errors,  because  it  has  no  meaning  without  reporting  those  other 
errors. 

MR.  CALLAGHAN:  It  gives  you  some  indication  of  what's  going  on.  I know  with  a simple  ballbar  I 
can't  do  a lot,  but  I can  at  least  have  some  idea  of  what  my  actual  squareness  is.  I realize  that  the  roll  and 
pitch  would  have  an  effect  on  it,  but  it's  not  the  whole  story,  though  it's  a piece  of  the  information  I didn't 
have  otherwise,  isn't  it? 

MR.  CALLAHAN:  Yes.  The  point  I'm  making  is  that  you  need  the  whole  data  set  to  make  a meaningful 
evaluation.  With  the  interim  checks,  you  take  a subset  of  that  and  that's  where  you're  looking  to  see  what 
has  changed,  but  you  have  to  have  the  whole  data  set  to  make  any  kind  of  reasonable  assessment  of  the 
machine  tool. 

MR.  CALLAGHAN:  But  it  tells  me  something. 
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DISCUSSIONS  ON  SIMULATION  TOOLS 


MR.  ESTERLING:  Chris  Deforge  and  I seem  to  be  the  "Lone  Rangers"  here,  and  maybe  together  we 
could  do  some  things.  However,  I just  wanted  to  respond  to  a question  asked  yesterday  about  what,  from  a 
software  perspective,  might  be  helpful. 

The  first  issue  is  in  terms  of  replicating;  you  might  want  to  distinguish  between  replicating  hardware 
versus  software.  If  Steve  Patterson  wants  to  replicate  what  Loyd  Bishop  did,  for  example,  he  would  want 
to  have  the  same  make,  the  same  model,  go  on  down  the  list,  including  the  same  maintenance  records. 

He’s  not  really  ever  going  to  really  replicate  what's  happening  in  a different  place,  but  you  want  to  be  able 
to  at  least  replicate  the  experiment  so  you  can  see  sort  of  what  variations  are  within  the  experiment. 

What  I would  suggest  as  a goal  for  the  software  is  we,  in  fact,  replicate  the  actual  machine  tool  as  it 
actually  is.  That's  different  from  replicating  the  experiment.  It's  actually  saying,  "Here  is  what  this 
machine  with  these  characteristics  can  actually  do."  So,  there  is  a subtle  difference  there  in  terms  of 
replication.  In  one  case  you're  just  trying  to  replicate  the  environment,  and  in  the  other  case  you're 
actually  trying  to  replicate  the  machine  as  if  it's  a virtual  CNC  with  those  characteristics. 

The  question  is,  what  are  the  requirements  you  would  want  for  this  simulation?  I think  that  leaves  a lot  to 
be  discussed.  The  first  issue  is  accuracy.  If  you're  worrying  about  the  sort  of  errors  that  are  being 
presented  here  you're  going  to  need  to  have  a very  accurate  modeling  system.  But,  at  the  same  time,  you 
don't  want  to  pay  a price  in  speed.  If  you  wanted  something  that's  practical  on  a shop  floor,  it’s  going  to 
have  to  be  something  which  is  going  to  be  reasonably  fast.  I can  tell  you  from  my  own  company's 
perspective  what  fast  means.  Back  when  we  sold  our  software  we  were  machining  in  a virtual  CNC  at 
roughly  the  same  speed  as  the  CNC  and  we  did  okay,  but  our  real  sales  took  off  when  we  were  actually 
able  to  machine  in  a virtual  CNC  environment  by  anywhere  from  a factor  of  10  to  100  times  faster  than  a 
physical  CNC.  I think  it’s  those  sorts  of  numbers  that  will  make  things  useful.  If  you're  running  at 
roughly  the  same  speed,  or  even  slower  than  the  CNC,  then  the  tendency  is,  "Well,  I'll  just  check  it  out  on 
my  machine  tool  itself,  machine  in  wax  or  something  like  that."  So  you  need  to  have  accuracy  to  model 
the  very  small  errors,  but  speed  in  order  to  maintain  some  sort  of  a practically  useful  tool. 

To  get  down  to  what  is  needed,  the  answer  yesterday  was,  "Well,  what  do  you  guys  need?"  and  that  should 
be  correct.  I mean,  if  we're  talking  about  a virtual  CNC,  then  we're  supposed  to  be  just  like  the  Loyd 
Bishop-Steve  Patterson  axis;  we  should  be  able  to  take  whatever  information  that  Loyd  gives  Steve  and  go 
away  and  model  that  CNC. 

The  more  practical  answer,  though  certainly  speaking  from  my  company's  perspective  and  in  terms  of 
cost,  in  terms  of  practicality,  is  that  the  higher  the  level  of  information  to  be  communicated,  the  easier  it's 
going  to  be  for  us.  The  notion  of  working  with  lots  of  different  sorts  of  raw  data  is  not  something  I would 
view  with  great  pleasure.  I would  rather  look  at  error  functions  as  a standard  way  of  communicating  the 
errors  that  are  in  that  system. 

There  is  a second  advantage  beside  the  cost  advantage,  which  is  the  issue  of  practicality  of  standardization. 
If,  in  fact,  all  these  different  machine  tools,  and  their  characteristics  represented  by  the  raw  data  are 
codified  in  some  kind  of  standard  way,  it'll  make  both  the  development  of  the  product  easier  and  also 
make  it  be  portable  across  vendors.  Different  vendors  will  have  the  same  kind  of  input  to  work  in.  So  I 
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think  standardization  here  will  be  very  important  in  terms  of  the  input. 

The  last  comment  I wanted  to  make  was  in  terms  of  the  kind  of  high  level  model  you  might  have.  There 
are  various  parametric  types  of  modeling.  I would  like  to  know  the  extent  that  these  linear  Taylor  series 
type  models  are  really  adequate  for  what,  for  example,  we  saw  from  Boeing,  and  other  people  yesterday.  I 
saw  some  very  interesting  non-linear  behavior  yesterday.  If,  in  fact,  the  errors  in  the  machine  tool  are  the 
errors  that  are  important  to  you,  then  I would  expect  non-linearities.  If  you  see  non-linearities  to  the  effect 
of  anywhere  from  1 to  10  of  the  area  you're  trying  to  model,  then  I would  think  those  non-linearities  might 
be  important. 

I saw  a couple  of  non-linearities  among  data  presented  yesterday.  One  example  was  that  at  the  various 
extremes  of  the  machine  tool  motion  you  saw  some  spikes.  That  may  or  may  not  be  important.  The 
Boeing  data  indicated  that  there  was  relatively  good  data  over  a certain  range,  and  it  then  began  to  take  off. 
That  kind  of  information  might  be  important  to  model.  By  just  doing  a straight-line  fit  you  may  be 
missing  some  very  important  sort  of  information  here. 

MR.  DEFORGE:  I have  a couple  of  comments.  I think  two  questions  had  to  be  asked:  what  is  it  that  we 
want  to  do  with  virtual  manufacturing  in  the  future;  but  first  we  need  to  ask  the  question,  what  is  it  that 
we're  capable  of  doing  today.  It's  important  to  ask  both  questions  so  that  we  make  sure  that  simulation 
companies,  such  as  ours,  keep  our  eyes  on  the  horizon  and  understand  the  needs  of  our  customers. 

Currently,  we  have  methods  of  taking  into  consideration  some  of  the  inaccuracies  of  a particular  machine, 
as  were  discussed  yesterday,  although  there  is  no  quick  fix,  there's  no  menu  selection  and  say,  "Let's  fill  in 
the  blanks,"  and  we're  done  with  it.  That's  not  where  we're  at  yet.  Hopefully,  someday  we  will  be  there. 

As  far  as  what  we're  doing  today,  we're  seeing  simulations  being  used  to  prove  out  machines  prior  to 
purchase,  to  make  sure  we’re  getting  the  right  equipment  for  the  right  job,  kind  of  take  a look  at  what  kind 
of  capacities  are  going  to  be  available  with  that  new  machine  tool,  prove  out  post-processors  prior  to 
equipment  being  delivered,  and  continually  using  the  simulation  models  to  prove  out  those  proposals,  to 
take  a look  at  cycle  time  issues  at  a relatively  micro  level  on  a tool-by-tool  basis  or  workpiece  by  work 
piece  basis,  or  the  overall  cycle  time  by  looking  for  collisions,  doing  collision  avoidance,  looking  for  near 
misses. 

So  what  kind  of  information  do  we  need  to  make  those  kinds  of  models  more  available  to  companies  other 
than,  the  big  ones,  to  the  small  or  medium-sized  businesses,  to  make  it  a reality  so  that  they  can  function 
in  this  highly  competitive  global  market  that  we're  constantly  hearing  about. 

What  I look  at  is  information.  I'm  going  to  reiterate  what  I said  yesterday  about  Hans'  presentation. 
Information  like  that  can  help  me  make  a model  a reality  quicker  today.  The  information  we  discussed,  as 
far  as  some  of  the  inaccuracies,  are  the  kinds  of  information  I'm  going  to  need  in  the  future.  So  I think 
what  we  have  to  keep  our  eye  on  is  what  we  need  today  for  virtual  manufacturing  and  where  are  we 
headed  in  the  future. 

As  far  as  CAD  data  goes,  we're  just  pretty  much  interested  in  the  outer  skins  of  a machine  tool  and  most  of 
the  time  we  can  get  that  information  relatively  easily.  We  need  the  position  of  each  individual  axis.  We're 
not  interested  in  knowing  where  every  bolt  is,  we're  not  interested  in  knowing  where  every  nut  is,  and 
things  of  that  nature.  That  type  of  information  bogs  down  a simulation. 
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Since  we  are  also  simulating  the  controller  of  the  machine  tool  where  we  get  bogged  down  is 
understanding  how  this  particular  controller  is  configured  for  this  machine  tool. 

When  we  talk  about  accuracy  we  have  two  accuracies  that  we  need  to  look  at.  One  is  the  accuracy  of  the 
process.  If  we're  looking  at  the  machine  tool  itself,  is  it  going  to  behave  in  the  way  that  we  would  expect  it 
to  behave  on  the  factory  floor?  For  instance,  if  we're  in  rapid  motion,  do  we  see  slow  motion,  or  are  we 
just  dealing  with  point-to-point  simulation? 

Accuracy  also  has  to  do  with  what  you  were  talking  about  earlier.  How  is  this  particular  machine  tool 
going  to  behave?  We  really  need  to  know  from  our  customers  if  that  is  how  they  intend  to  use  the 
simulation.  Do  they  want  to  have  a simulation  that  is  "the"  machine  tool  on  an  engineer's  desk?  I don't 
know  that  answer  yet.  But  to  date,  that  really  hasn't  been  the  big  push  for  us;  we've  been  using  the 
simulation  more  as  a macro  investigative  tool,  not  a micro-analysis  type  tool. 

The  other  accuracy  has  to  do  with  the  CAD  geometry  itself.  I mean,  if  we're  talking  about  looking  at 
machine  tools  as  precisely  as  was  being  discussed  yesterday,  we  have  to  make  sure  that  we  get  good  CAD 
geometry  for  the  machine  tool  up  front.  It's  not  going  to  matter  if  I have  an  axis  that's  off  by  100 
thousandths  of  an  inch  if  my  CAD  geometry  is  bad  going  in.  So  I don't  know  how  we  plan  on  dealing  with 
that;  if  we're  going  to  try  to  make  CAD  geometry  available  to  everybody  through  some  type  of  repository, 
or  just  information  about  "These  are  the  dimensions,  now  make  it  yourself."  But  I think  it's  really 
important  to  say  what  can  we  do  today  and  what  information  do  you  need  to  make  that  happen  and  what 
are  we  going  to  need  tomorrow. 

MR.  DONMEZ:  From  the  perspective  of  what  we  need  for  tomorrow,  the  example  that  you  gave,  like  a 
computer  in  front  of  an  engineer  to  analyze  what  he  or  she  can  do,  given  a part  geometry,  would  be  a very 
useful  tool. 

MR.  CALLAGHAN:  Alkan,  I think  I disagree  with  you  on  that.  I think  the  first  step  is  to  provide  tools 
for  the  shop  floor  maintenance  people  so  they  can  visualize  what's  wrong  with  the  machine. 

MR.  DEFORGE:  I can  understand  why  you'd  be  interested  in  that,  but  I'm  telling  you  that  it's  not  where 
the  thrust  of  our  business  is  right  now.  I know  that  simulations  are  currently  being  used  in  a design  phase 
to  understand  the  overall  process  and  to  get  a macro  look  at  the  process.  Is  it  possible  for  this  machine 
tool  to  make  this  particular  item?  What  are  the  quality  issues  if  we  decide  to  use  this  machine  tool  is  not 
the  question  being  addressed  in  our  software  currently.  Can  this  machine  tool  even  get  into  the 
configuration  necessary  to  cut  this  part  and,  if  so,  how  long  is  it  going  to  take,  what  kind  of  program  is 
going  to  be  necessary,  what  kind  of  fixturing  can  we  think  of  using?  We're  not  even  talking  about  the 
issues  of  looking  at  the  flexing  of  the  work  piece  due  to  fixturing.  That's  something  we're  not  doing  in  our 
simulations  and  we're  basically  a rigid  body  simulation;  we  can’t  take  that  kind  of  information  into  account 
today.  The  main  reason  is  that  you  have  to  keep  an  eye  on  how  long  it  is  going  to  take  to  run  this 
simulation.  What  kind  of  hardware  do  we  have  available  today?  We  would  all  like  to  walk  in  and  say, 
"Computer,  give  me  a machine  tool,  and  let's  run  it."  We're  not  there.  Maybe  someday  we  will  be,  but 
we're  not  there  yet.  So  I think  we  have  to  keep  our  eye  on  what  can  we  do  now,  but  we  can't  ignore  the 
kind  of  information  that  you're  gathering. 

MR.  CALLAGHAN:  I raised  that  issue  because  there  are  lots  of  machines  that  are  over  25  years  old  in 
service  every  day.  I would  say  the  vast  majority  of  parts  made  here  in  the  States  are  made  on  machines 
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over  25  years  old,  and  those  are  the  ones  that  need  the  highest  level  of  maintenance.  This  is  where  there  is 
the  largest  degree  of  interest  in  looking  at  machine  capability  and  making  corrections  to  these  machines. 

MR.  HEMERLE:  To  simulate  the  machine  you  would  need  to  know  whether  it's  a primed  axis  or  un- 
primed axis.  Would  you  need  to  know  the  feedback  system?  Because  I look  for  entirely  different  errors 
depending  on  the  machine  design  and  configuration.  Where  people  list  21  parameters,  I track  72 
significant  degrees  of  freedom  and  there  are  many  more  that  I don't  do  because  I'm  not  at  that  level  of 
precision.  I'm  not  involved  with  rigidity,  and  that's  a whole  area  that  is  going  to  determine  how  fast  I can 
cut  and  what  is  the  resulting  part  going  to  be.  I think  it  would  be  an  extremely  long  way  away  before  I 
would  want  virtual  machining  to  tell  me  anything  about  the  expected  part.  What  I'm  looking  for  is,  from 
the  error  characteristics  that  I observe,  what  are  the  mechanical  elements  inside  that  machine  responsible 
to  contain  those  errors  and  how  do  I identify  them  and  their  condition.  Not  what  is  it  now,  but  the 
trending.  When  I see  changes  in  my  bidirectional  data,  changes  in  the  observed  lost  motions,  how  do  I 
interpret  what  is  happening  to  the  condition  of  the  machine? 

So,  to  simulate  a machine  isn't  like  simulating  one  generic  machine.  My  machine  A is  entirely  different 
than  my  machine  B and  the  serial  numbers  are  one  different.  So  how  is  the  trending  in  that?  I see 
modeling  to  help  me  understand  why  machine  A is  different  than  machine  B and  how  to  adjust  to  it. 

MR.  ESTERLING:  Dave,  I think  you  would  also  want  to  distinguish  between  different  types  of  machines 
You're  thinking  a lot  in  terms  of  five  axis  machines,  three  axis  machines,  and  then,  turning  lathes.  There 
are  different  levels  of  complexity  here  and  also  different  levels  of  interest.  We’ve  already  done  some  work 
in  turning  for  Alkan,  and  I think  we  have  the  sort  of  modeling  that  nowadays  is  required  for  turning  to 
actually  model  a machine  for  it.  I would  suggest  that  3-axis  milling  is  within  reach,  is  an  achievable  goal, 
within  this  year.  5-axis  is  yet  another  ball  game.  We  have  a little  more  standardization  with  3-axis 
machines. 

There  is  another  aspect.  Are  you  trying  to  model  the  macro  model,  the  overall  machine  tool 
characteristics?  Are  you  worrying  about  the  kinematics?  Are  you  concerned  about  the  low  level  material 
rules  for  the  process?  Which  of  these  things?  Different  companies  have  different  strengths  in  that  area  in 
terms  of  being  able  to  deliver  different  kinds  of  products  there.  An  issue  here  is  where  do  we,  as  vendors, 
need  to  focus  in  order  to  meet  your  needs?  Is  it  modeling,  the  overall  sort  of  machine  tool  fixturing  tool 
change  environment?  Is  it  modeling  the  material  removal  process?  Those  are  the  issues  which  I think  we 
need  some  direction. 

MR.  CALLAGHAN:  I think  what  Dave  was  trying  to  say  was  that  we'd  like  to  be  able  to  present  to  the 
maintenance  people,  primarily,  illustrations  of  what  the  physical  errors  are,  in  a machine  and  be  able  to 
track  that  over  a period  of  time  to  say,  "Okay,  today  we  corrected  this  machine  to  take  the  bend  out  of  it, 
and  we  came  back  three  months  later  and  the  thing  is  still  bent.  Why  is  it  still  bent?" 

MR.  DEFORGE:  That's  a whole  new  focus.  That's  a whole  new  focus  from  what  we've  used  simulation 
for  and  yesterday  is  the  first  time  I entered  into  that  kind  of  discussion  for  simulation  to  be  used  in  that 
manner.  So,  just  from  a company  perspective,  we  would  have  to  take  a look  at  the  marketability  of  that 
kind  of  technology  and  if  that's  something  we  can  invest  a whole  lot  of  time  in. 

MR.  CALLAGHAN:  The  reason  why  I raise  this  issue  is  Dave  and  I do  it  every  day.  We  do  it  with  little 
cartoons  that  we  draw  for  the  fellows  at  work  saying—  "Okay,  this  is  the  way  the  machine  is  going.  We 
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have  to  go  to  that  comer  right  there  and  you  have  to  raise  it  up  to  take  that  error  out." 

MR.  DEFORGE:  I think  that's  easily  attainable.  I know  that,  for  instance,  in  our  package  for  each  degree 
of  freedom  we  can  control  the  motion,  the  kinematics,  of  that  particular  motion  with  a mathematical 
equation.  So,  if  you  can  hand  me  an  equation  that  describes  that  type  of  motion,  we  can  make  it  happen. 

MR.  DONMEZ:  But  the  problem  is  the  scale.  You  have  nominal  motion  that  you're  simulating  and  then 
Buzz  gives  you  an  error  which  is  about  one-thousandth  of  an  inch.  To  be  able  to  show  what's  happening 
to  the  machine  in  those  two  different  scales  is,  I think,  a bit  of  a challenge. 

MR.  CALLAGHAN:  No.  What  I relate  it  to  is  mold  analysis.  They  do  the  same  thing  with  mold 
analysis,  except  that  the  moving  structures  are  static,  vibrating  in  space,  and  I would  visualize  something 
similar. 

MR.  ESTERLING:  That  gets  back  to  what  I mentioned  about  the  speed  and  accuracy  being  important 
here.  You  can  always  exaggerate.  You  can  scale-up  the  error  in  some  way,  but  in  order  to  be  able  to  scale 
it  up  properly  you'd  still  need  to  be  able  to  model  it  down  at  the  micro  level  in  terms  of  what  is  happening. 

MR.  DONMEZ:  I think  what  we're  hearing  is  three  different  types  of  approach  to  the  simulation.  One  is 
what  is  happening  to  the  part,  just  from  the  point  of  view  of  tool-work  interface.  Chris  is  talking  about  the 
whole  machine  moving  and  then  adding  the  errors  to  look  at  the  part  eventually.  But  Buzz  is  saying  just 
look  at  the  machine  only  and  show  what  the  convolution  of  all  these  different  types  of  errors  produce. 
They're  somewhat  related,  but  are  three  different  directions. 

MR.  HEMERLE:  Looking  at  the  part,  to  me,  is  somewhat  analogous  to  being  an  industrial  paleontologist. 
You're  looking  at  a footprint  of  a dinosaur,  trying  to  describe  the  dinosaur.  Asset  preservation  is  what  is 
the  quality  of  that  machine  tool.  The  part  is  a by-product.  If  you  can  describe  the  machine  tool,  you  know 
what  is  coming  out,  but  you  can  describe  a part  and  not  have  any  insight  into  what  is  going  on  in  that 
machine.  You  might  be  able  to  tie  it  back  to  your  model. 

MR.  DEFORGE:  Technology  is  not  there  to  be  able  to  deal  with  that  yet.  It's  not  there.  But  I think  we 
have  to  be  positioned  to  take  advantage  of  that  technology  when  it  becomes  available. 

MR.  HEMERLE:  The  errors  and  conditions  are  there— people  are  dealing  with  it— and  technology  is 
merely  to  assist  them  in  doing  it  better  today  than  yesterday. 

MR.  DEFORGE:  When  I refer  to  technology,  I'm  referring  specifically  to  my  technology,  to  simulation 
models.  That's  why  I said  yesterday  that  we  see  bits  and  pieces  of  this  throughout  the  computer 
information  industry;  that  company  A is  able  to  handle  this  kind  of  information,  company  B is  doing  some 
finite  element  analysis,  and  we're  doing  some  dynamic  modeling.  To  bring  all  that  together  into  one 
software  package  with  today's  technology  would  mean  let's  get  a Cray  computer  on  everybody's  desk,  and 
that's  not  realistic.  So,  let's  focus  in  on  specific  tools  for  specific  jobs.  Currently  we  can't  always  bring 
them  all  together.  That's  why  I say  we  don't  have  the  whole  deck  yet,  but  we  have  parts  of  it. 

MR.  ESTERLING:  Chris'  company  and  our  company  take  somewhat  different  approaches  toward  the 
marketplace.  Chris'  company  has  focused  more  on  the  high-end  user,  which  is  well  represented  here,  and 
our  company  has  focused  on  the  low-end  user.  It's  probably  reflected  on  our  pricing,  as  well  as  the 
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number  of  seats  sold.  Our  focus  has  been  on  what  horsepower  available  on  the  small  shop  floor.  Our 
focus  is  to  deliver  a product  which  will  work  on  what  today's  computers  have  or  maybe  what  tomorrow's 
computer  will  have  within  a year  or  so.  It's  a different  modeling  structure  and,  again,  as  you  look  at 
different  vendors,  there  is  a handful  of  vendors  out  there  doing  what  we  do  and  each  of  us  has  our  niche. 
There  are  two  issues  to  be  concerned  with  here.  One  of  them,  as  Chris  has  already  pointed  out,  what  are 
these  different  vendors  doing  today  and  what  can  they  be  doing  tomorrow.  I think  the  critical  point  is  the 
marketability.  None  of  us  are  there  in  terms  of  what  you're  asking  for  now  and  for  any  of  us  to  make  that 
move  and  start  doing  something,  there  will  have  to  be  some  market  signal.  The  market  signal,  among 
other  things,  would  be  a specification  in  terms  of  what  you  want.  That's  where  this  meeting  has  been  very 
helpful  for  all  of  us  in  terms  of  what  your  specifications  are. 

MR.  YUAN:  In  cooperation  with  University  of  Illinois  and  Northwestern  University,  we're  developing  a 
project  also  called  the  "Virtual  Machine  Tool."  Our  idea  is  that,  if  you  have  internal  error  components  you 
already  measured,  then  we  have  a model  and  we  can  transfer  that  to  the  volumetric  error.  If  you  have  a 
machine,  then  you  use  what  we  call  a topology  model  to  describe  this  machine.  You  have  work  piece 
branch  and  you  have  a tool  branch.  For  the  work  piece  branch  maybe  you  have  X axis  and  Z axis,  and  for 
the  tool  branch  you  may  have  Y axis,  then  you  input  the  topology  model  and  then  software  can  develop 
the  volumetric  model  automatically.  Then,  you  have  to  do  error  components  as  inputs  and  the  output  will 
be  the  volumetric  error.  If  you  are  cutting  a part,  then  you  have  a path,  and  from  this  path  you  can  get  the 
volume  along  this  path  so  then  you  can  know  what  is  the  form  error  along  the  path.  That  is  a theoretical 
volumetric  error  from  your  individual  error  components.  This  is  what  we  are  supposed  to  do.  We  catalog 
all  the  data  in  the  topology  model  and  how  to  automatically  formulate  the  volumetric  sensitivity  model 
according  to  the  topology  model.  This  part  has  been  completed,  and  other  parts  are  still  ongoing  and 
underway. 

MR.  ESTERLING:  All  these  discussions  reminded  me  of  something  that  I think  is  important  to  be 
mentioned  in  terms  of  this  database  that  NIST  is  putting  together.  There  is  a spin-off  of  this  effort  that  is 
very  important  to  our  companies.  We  are  hungry  for  data  about  different  machine  tools,  the  ideal  machine 
tools.  By  creating  this  database  you're  going  to  be  providing  us  information  about  how  that  machine  is  set 
up  in  terms  of  for  a given  manufacturer,  a given  model,  irrespective  of  the  error  component  there.  In  fact, 
information  about  the  actual  set-up  of  the  machine  tool  is  going  to  be  very  useful  to  us,  particularly  as  you 
get  into  multi-axis  type  machine  tools.  So,  it's  not  your  agenda,  but  that  data  is  going  to  be  very  helpful  to 
us. 


MS.  KRULEWICH:  As  far  as  Buzz’s  requirement  about  displaying  particular  types  of  errors  is  concerned, 
it  wouldn't  be  that  far  of  a leap  to  take  a particular  machine  and  exaggerate  the  squareness  of  one  axis  for 
maintenance  and  repair  purposes. 

The  other  comment  I want  to  make  is  related  to  the  errors  resulting  on  the  part,  if  the  concern  is  the  part. 

If  you  have  a particular  type  of  machine  with  a particular  type  of  error  and  you're  going  to  machine  a part 
with  that  machine,  then  in  the  design  phase  you  can  intelligently  tolerance  your  part,  especially  if  it's  an 
assembly  with  multiple  stacks  of  parts.  You  can  intelligently  tolerance  your  part  based  on  the  performance 
of  your  machine.  I think  that  there  is  a use  for  knowing  what  the  resulting  errors  on  the  part  are,  not 
necessarily  for  diagnostics  purposes,  but  more  for  the  purpose  of  the  designing  of  the  part.  But  it  doesn't 
need  to  occur  in  real  time  with  this  simulation.  Because  you're  not  going  to  see  the  machine  move  with 
those  errors.  So,  that  could  be  something  completely  in  the  background  and  then  you  maybe  form  the 
figure  of  the  part  with  exaggerated  errors  when  it's  done,  but  that  wouldn't  need  to  happen  in  a real-time 
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simulation. 


MR.  DEFORGE:  In  our  simulation,  the  creation  of  the  part  is  the  result  of  the  machine  tool's  motion.  So 
we're  actually  taking  the  tool  through  the  work  piece  as  would  happen  in  reality  and,  depending  on  how 
that  motion  is  defined  is  going  to  determine  your  work  piece.  So,  we're  not  taking  CL  data  and  saying, 
"Let's  look  at  the  description  of  the  part  based  on  that,  and  here's  your  geometry."  We're  actually  taking 
the  G&M  code  and  driving  the  virtual  model  and  the  finished  part  is  the  result  of  that  motion. 

MS.  KRULEWICH:  When  you're  talking  about  computation  time,  I guess  what  I'm  thinking  is  that  it 
doesn't  have  to  be  displayed  on  the  screen,  while  the  machine  is  moving. 

MR.  DEFORGE:  That's  absolutely  true.  Because  of  limitations  in  hardware  technology,  basically  what  we 
always  do  for  our  customers  is  we  draw  up  this  triangle  and  we  say  you  have  extent,  accuracy  and  speed 
on  this  triangle,  and  for  any  simulation  run  we  say,  "Pick  two."  That's  what  you're  going  to  get.  Let's  say, 
if  you  want  speed  and  accuracy,  you're  going  to  have  to  sacrifice  extent.  If  you  want  extent  and  speed, 
then  you're  going  to  have  to  sacrifice  accuracy.  That's  simply  because  of  where  we're  at  with  hardware 
technology,  not  with  software  technology.  We're  seeing  some  significant  changes  in  hardware  technology 
that  are  making  those  kinds  of  tools  less  and  less  necessary.  Those  are  limitations  that  we  live  within  in 
the  computer  industry.  But,  to  duplicate  squareness  is  completely  doable.  On  the  geometry,  if  you  say, 
"Here  is  my  base.  I'm  going  to  lay  my  X axis  on  top  of  this  base  right  here,"  we're  going  to  put  a 
coordinate  system  right  there  where  it's  supposed  to  go.  Now,  I can  adjust  that  coordinate  system  anyway 
you  want.  I could  attach  two  coordinate  systems  to  that  same  place,  one  could  be  used  along  the  X axis 
and  the  other  could  be  used  along  the  Y axis.  So,  I have  the  ability  then  to  move  those  coordinate  systems 
about.  That's  completely  doable  and  very  accurately,  within  a micrometer. 

QUESTION:  Can  you  simply  take  the  inspection  data  and  feed  that  in  though? 

MR.  DEFORGE:  No.  That's  what  I said  earlier;  I don't  have  a button  that  I can  push  today  and  say,  "Let's 
make  those  adjustments." 

QUESTION:  But  do  you  think  it's  doable? 

MR.  DEFORGE:  Absolutely.  I know  that,  for  instance,  I could  write  a macro  right  now.  I have  the  tools 
to  make  that  happen.  I could  write  what  we  call  a GSL,  a graphic  simulation  language  macro,  so  that  you 
could  press  a button  and  ask  for  the  parameters  and  adjust  each  one  of  these  tag  points,  or  each  one  of 
these  coordinate  systems. 

MR.  DONMEZ:  If  you  have  a simulation  of  a slide,  for  example,  can  you  put  all  six  degrees  of  freedom 
errors  on  the  slide  and  show  that? 

MR.  DEFORGE:  Yes,  because  with  the  way  that  we  handle  each  axis  motion,  the  system  says,  based  on 
the  menu  selected,  that  this  axis  moves  along  X,  this  one  moves  along  Y.  But  I can  go  in  and  make  a more 
detailed  definition  of  how  that  is  supposed  to  move  based  on  a programming  language  which  you  would 
actually  walk  in  and  lay  out  the  mathematical  equations.  So,  if  it  moves  along  more  than  one  axis,  as  long 
as  we  can  describe  that  with  a mathematical  equation,  then  we  can  duplicate  the  motion. 

MR.  CALLAGHAN:  Alkan,  I'd  like  to  take  a minute  and  try  to  put  all  this  stuff  in  perspective  since  I've 
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been  messing  around  with  this  stuff  for  almost  15  years.  To  have  this  work,  there  are  several  stages  that 
have  to  be  accomplished  before  we  even  start  to  talk  about  what  Debbie  talked  about  with  simulations.  I 
think  the  first  phase  was  to  get  the  instrumentation  commercially  available  with  systems  that  will  gather 
the  data  and  get  it  in  a format  where  it's  usable.  I think  we’re  pretty  well  along  that  right  now.  You  know, 
there  is  a number  of  products  out  there  right  now,  there  is  a lot  of  things  you  can  do  to  gather  this  data. 

The  second  step  is  to  apply  that  correctly  to  the  machines,  to  get  the  machines  stabilized  mechanically, 
thermally,  and  so  forth.  We’re  not  even  close  there  yet.  We  have  scratched  the  surface.  I would  guess 
that  less  than  one  percent  of  the  machines  in  this  country  could  use  what  Debbie  is  suggesting  as  a model 
because  we  don’t  know  enough  about  the  geometries  of  these  machines  are  from  day  to  day.  There  are  a 
few  machines  that  are  in  controlled  environments  that  are  using  these  tools,  that  have  the  measuring 
instruments.  Users  stabilize  these  machines  on  a regular  basis  and  they  measure  them  periodically,  but, 
for  the  most  part  we  don’t  have  the  stabilized  conditions  in  the  machines  where  we  get  a lot  of  value  out  of 
doing  a simulation.  You  can  do  it  in  the  laboratory  but  you’re  not  going  to  do  it  in  the  shops  right  now. 
We’re  fighting  continually  with  management  over  other  techniques  to  stabilize  the  machines  so,  when  I 
come  back  and  measure  the  next  time,  I get  reproducible  results. 

MR.  DONMEZ:  I think  you're  absolutely  right  in  that  respect  but,  this  is  reality.  If  this  is  reality,  we  need 
to  have  a representation  of  that  reality,  and  the  best  representation  of  reality,  I believe,  is  to  introduce  some 
of  these  terms  into  our  models. 

MR.  CALLAGHAN:  The  problem  is  that  most  of  these  are  outside  the  tolerance  limits  of  the  parts  you're 
trying  to  produce.  Dave  Hemmerle  has  coined  some  words  that  are  kind  of  interesting.  Right  now  most 
manufacturing  is  done  in  what  is  known  as  "gauged  base,"  and  that's  Dave's  term.  That  means  that  they 
take  a trial  cut  on  the  part  and  they  come  in  and  apply  a gauge  to  that  part  and  make  a correction  to  the  tool 
offset  and  then  finish  the  part.  Now,  that  gauge  space  application  is  the  way  they're  able  to  produce  these 
close  tolerances.  There  is  operator  intervention.  It  is  correcting  for  the  changes  that  we  can  measure.  The 
management’s  position  is  that  the  process  is  working,  let's  not  mess  with  it. 

There  are  a few  places,  like  Dave’s  company,  that  are  successful  in  developing  what  we  call  "machine 
space  applications."  This  is  the  case  where  you  can  do  a simulation  and  you  can  come  up  with  some 
reasonable  numbers.  But  I would  venture  to  say  that  less  than  one  percent  of  all  the  machines  in  this 
country  are  truly  running  machine  space  applications.  A lot  of  people  think  they  have  that,  and  a lot  of 
systems  have  failed.  We  would  like  to  have  something  that  we  could  present  to  management,  a picture 
that  says,  "Okay,  you  just  paid  a half  a million  dollars  for  this  machine  to  go  in  a straight  line  within  ten- 
thousandths.  It's  installed  and  it's  going  at  a tenth  of  a thousandth.  You  come  back  a week  later  the 
environment  has  changed  and  this  machine  that  you  just  paid  a half  a million  dollars  for  is  now  five  ten- 
thousandths  of  an  inch  bowed  up." 

This  is  my  reality.  I'm  living  with  this  every  day  and  trying  to  get  people  to  stabilize  the  machines  enough 
so  that  we  could  do  some  predictive  analysis  on  them.  We  can't  do  it  yet.  We  need  that  first  step.  We 
need  to  be  able  to  provide  to  the  maintenance  mechanics,  and  to  their  supervisors,  a real  simplistic 
representation  of  the  errors  within  the  machine.  That's  the  first  step. 

MR.  ESTERLING:  I agree.  My  point  is  that  you  really  need  both.  For  example,  the  nice  thing  about 
software  is  you  can  play  the  "what  if'  scenario.  That's  a lot  harder  to  do  on  the  shop  floor.  If  you  wanted 
to  make  a presentation  to  management  and  say,  "Now  here  is  what's  going  to  happen.  You've  got  a 
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machine  tool  whose  errors  you  can't  see.  But  let's  make  a part.  Let's  do  a 'what  if  sort  of  part  that  you're 
going  to  run  on  that  thing.  Now  let  me  show  you  in  some  way  that's  fairly  dramatic  to  that  manufacturer 
that  this  part  is  out  of  tolerance."  Then  you're  not  just  talking  about  the  artifact,  but  you're  talking  about 
the  part  this  guy  wants  to  deliver  off  to  someone  else.  So  I suggest  both  aspects  are  needed.  You  need  to 
go  in  both  directions.  The  advantage  of  software  is  that  you  have  this  ability  to  play  and  explain  things  to 
the  maintenance  engineer  at  one  level,  to  management  at  another  level,  and  it  all  ties  together.  That's 
really  what  hopefully  we  offer  in  terms  of  value-added  here. 

MR.  DEFORGE:  We're  going  to  create  this  database  of  information,  now  who  is  going  to  be  able  to  use 
that?  How  useful  is  this  information?  You  know,  you're  willing  to  give  your  database  and  all  this 
information  to  me,  but  what  does  that  really  mean  to  me,  in  my  business?  You  say,  "I  have  machine  A and 
I have  machine  B sitting  side-by-side.  They're  the  same  make,  the  same  model  number.  They  are  one 
digit  different  in  their  serial  number,  yet  they  both  act  uniquely."  So  now,  what  does  a national  repository 
of  that  kind  of  information  do  for  me? 

MR.  ESTERLING:  But  doesn't  it  give  you  some  kind  of  statistical  data  so  you  know  what  kind  of 
variation  you've  got  for  a given  class  of  machine  tool  across  the  country  and  across  environments  of  what 
you  have?  Now,  is  that  useful  or  not? 

MR.  CALLAGHAN:  I don't  think  so,  because  you're  going  to  have  different  levels  of  maintenance. 

MR.  DONMEZ:  I think  the  issue  is,  if  you  have  machine  A and  machine  B that  are  behaving  differently, 
you  know  they  are  behaving  differently  because  you  have  data  on  them.  If  you  have  data  on  them,  you 
can  use  that  data  to  predict  what's  going  to  happen  using  machine  A or  machine  B. 

MR.  DEFORGE:  Suppose,  if  we're  using  this  data  to  help  understand  the  problem  and  to  help  vendors 
such  as  my  company  understand  where  we're  going  with  this  information  in  the  future  and  how  we  need  to 
tailor  our  software  to  accept  this  information,  then  that  is  of  value.  Basically,  let's  look  at  the  kind  of 
information  that's  being  collected  and  the  kind  of  information  that's  needed  to  bridge  this  gap  between 
virtual  reality  and  reality,  and  what  kinds  of  things  do  we  need  to  look  at  to  do  that.  That  does  become  of 
value.  But  I'm  looking  for  something  that's  even  more  basic  than  that,  more  standard  than  that,  that  Fanuc 
has  this  many  controllers,  and  this  is  the  kind  of  information,  the  kind  of  syntax,  that  they're  expecting  on 
their  G&M  code. 

MR.  CALLAGHAN:  You  want  generic  average  readouts. 

MR.  DEFORGE:  Absolutely. 

MR.  CALLAGHAN:  What  I am  looking  at,  and  what  he  is  looking  at,  I believe,  are  very  specific 
applications,  and  so  my  maintenance  people  may  maintain  the  machine,  the  same  machine,  totally 
different  than  his  configuration,  or  his  accuracies,  so  I really  see  that  specifics  in  the  data  base  would  be  of 
very  little  value  because  there  would  be  wide  ranges  between  those  and  you  wouldn't  say,  "Well,  what  is 
the  specific  machine  I've  got  to  deal  with."  But  you're  looking  for  more  of  an  average  generic  call-out  for 
the  machine  and  I don't  know  if  that  should  maybe  come  from  manufacturers  or  the  people  that  build  them 
and  get  them  on  board  with  this  kind  of  information  and  the  methods  of  reporting  the  information,  get 
them  to  do  that,  but  it's  still  going  to  be  wildly  varied,  depending  on  where  you're  at. 
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MR.  HEMERLE:  They  already  do  that,  don't  they?  They  error  budget  by  characteristics  when  they  make 
up  the  machine? 

MR.  CALLAHAN:  Not  all  of  the  parameters,  I don't  believe.  They  don’t  publish  them. 

MR.  HEMERLE:  They  don't  publish  them  but,  let  me  tell  you,  that's  where  they  make  their  money  and 
could  be  why  they're  not  here. 

MR.  JOHNSON:  It  seems  to  me  that  what  we're  talking  about  doing  here  could  be  useful  information  over 
a whole  spectrum  of  activities,  from  a production  floor  all  the  way  back  to  the  customer  for  some  product 
that  is  describing  what  the  requirements  are  to  some  company  that's  going  to  design  and  produce  that  for 
him.  Our  environment,  where  I work  at  Texas  Instruments  (TI),  for  instance,  our  customer  may  want  a 
laser  range-finder  for  one  of  their  tanks,  or  something  like  that,  and  to  just  take  one  requirement,  they 
might  want,  a detection  range  of  3 km,  or  they  might  want  a detection  range  of  10  km,  and  if  they  want 
one  for  10  km  that's  going  to  turn  into,  eventually,  a lot  tighter  tolerances  on  the  piece  parts  that  go  into 
that  and  the  electronics  that  go  into  that.  So,  they  hand  those  requirements  off  to  our  systems  engineers 
and  the  systems  engineers  determine  what  kinds  of  components  need  to  go  in  here,  which  drive  the 
manufacturing  processes  that  are  going  to  be  used  to  build  those  types  of  components,  and  then  they 
allocate  those  tolerances  down  into  the  sub-components  and  give  those  to  the  lead  engineers,  and  then  they 
sub-allocate  those  tolerances  down  to  the  individual  features  in  those  components.  And  then,  that's  how, 
that  one  and  a half  inch  diameter  ends  up  with  a plus  or  minus  a tenth  of  a mm  tolerance  on  it.  Those 
systems  engineers  can  use  the  information  that  we're  talking  about  generating  here  at  a higher  level  of 
abstraction,  of  course,  they  don't  care  about  feeds  and  speeds  and  depth  of  the  cut,  but  they  need  to  have 
manufacturing  information  to  make  the  right  decisions  about  the  right  types  of  components  if  they  have 
alternatives  that  they  can  pick  from  that  are  going  to  be  less  costly  to  manufacture  because  of  the 
manufacturing  costs  and  the  tolerances  involved.  So,  it  seems  to  me  that  we  probably  need  to  get  a 
broader  spectrum  of  people  involved  that  perform  different  functions  in  putting  together  a road  map  for 
what  needs  to  be  developed  first.  Obviously,  some  things,  the  modeling,  needs  to  be  done.  We  need  to 
collect  some  data,  we  need  to  validate  the  way  we  model  these  machine  tools  and  what  they're  capable  of 
before  we  can  move  up  to  the  next  level  of  abstraction  and  start  embedding  that  into  CAD  tools  so  that  the 
design  engineers  can  understand  what  they're  doing.  Then  we  need  to  move  up  to  the  next  level  of 
abstraction  so  that  the  systems  engineers  know  what  the  impact  of  the  decisions  that  they're  making  are.  It 
may  be  10  to  12  years  down  the  road  by  the  time  we  get  to  the  point  where  we  really  have  good 
information  for  them  to  use.  But,  as  we  move  upstream  in  higher  levels  of  abstraction  in  modeling  this 
capability,  I think  that  the  design  engineers  are  going  to  get  some  level  of  use  out  of  just  being  able  to  go 
to  the  manufacturing  facility  and  understand  the  model  for  manufacturing  certain  types  of  parts.  There  is  a 
certain  amount  of  information  that's  going  to  come  out  of  this  pretty  early  that  could  be  embedded  in 
analysis  tools  that  are  being  developed  right  now  for  design  engineers. 

So,  we  need  a road  map  for  future,  may  be  for  3 to  5 years  or  2 to  3 years  into  the  future,  then  say,  "Okay, 
now  we  have  visibility  for  5 to  10  years  out."  We  need  to  get  the  right  people  involved  so  that  we  can  at 
least  all  have  an  input  for  where  we  are  in  that  whole  product  life  cycle  and  what's  important  to  us.  A joint 
development  of  a road  map  like  that  is  a real  good  tool  for  getting— if  it's  facilitated  properly— a lot  of 
information  out  on  the  table  so  that  it  can  be  sorted  out,  categorized  and  then  put  in  some  chronological 
order.  From  this  roadman,  we  can  generate  plans  for  how  we're  going  to  develop  this  and  then  put  some 
dates  and  times  that  are  reasonable  on  when  to  expect  to  achieve  those. 
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MR.  ESTERLING:  The  market  is  driving  that  already.  The  major  CAD  vendors  are  talking  to  even  little 
guys  like  us,  and  Deneb  to  do  this  integration  of  manufacturing  into  the  CAD  environment.  There  is  lots 
of  hurdles  to  get  past,  not  the  least  of  which  is  the  whole  sort  of  outlook  that  the  designer  has.  But  at  least 
by  making  a clean  environment  inside  a Personal  Computer,  let's  hope  the  designer  might  actually  get  a 
little  dirtier  in  terms  of  what's  happening  on  the  shop  floor.  That's  the  goal,  but  there  a lot  of  market  push 
in  that  direction  already. 

MR.  MA:  One  obligation  for  the  simulation,  for  the  rating  of  machines,  is  to  see  how  good  the  machine 
can  be,  what  kind  of  part  it  can  make.  In  some  situations  I understand  the  companies  are  trying  to  relate 
the  manufacturing  data  to  the  sales.  They  have  a bunch  of  machines  and  they  want  to  put  all  this 
inspection  data  and  then  form  a model  so  that  when  the  sales  or  marketing  are  trying  to  get  some  business 
they  are  putting  in  the  problems  and  see  which  machine  is  available  and  then  whether  they  have  capability 
or  not.  If  the  simulation  can  create  a model  showing  a part,  say  a basic  dimension,  how  to  do  it,  and  then 
that  would  help  them  make  a better  decision. 

MR.  CHANDRASEKHARAN:  I've  been  sitting  very  quietly  because  we've  gone  through  something  very 
similar  like  this  before  when  we  talked  at  Caterpillar  of  why  we  wanted  to  get  into  something  like  this,  and 
I clearly  hear  that.  Everybody  tends  to  gravitate  toward  where  the  problem  is  focused  more  at.  For 
instance.  Buzz  and  Dave  are  talking  about  looking  at  the  machine  and  how  it  is  moving,  and  somebody 
else  is  talking  about  the  part,  and  somebody  is  not  talking  about  variability  saying  that's  not  important. 
What  we  heard  is  all  these  issues  are  very  important  to  us  because  we  take  a part,  if  it's  in  a cell,  a cell 
controller,  it  could  send  it  to  any  of  the  machines  depending  on  what  is  available,  so  you  have  variability 
in  your  product  coming  in  right  there,  and  different  machines  are  behaving  differently  and  we  need  to 
capture  that.  We  want  to  send  it  up  to  the  design  stage  in  a manner  that  they  were  talking  at  TI,  but  the 
core  of  the  problem  is  lack  of  data,  and  I think  that's  why  yesterday  I was  trying  to  show  that  we  need  to 
de-emphasize  some  of  the  simulation  aspects  because  different  people  here  want  to  use  it  differently.  The 
core,  again,  is  the  data,  how  do  we  store  the  data,  the  completeness  of  the  data  to  perform  each  of  these 
functions,  and  I can  see  that  as  being  a very  useful  outcome  of  this  project,  and  that's  how  we're  getting 
involved  in  this.  Now  that  we're  collecting  this  machine  characterization  data,  if  that's  truly  a 
characterization  of  the  machine,  it  should  be  able  to  support  all  of  these  functions,  not  just  one  or  the  other, 
and  we  see  that  clearly  happening.  The  variability  across  these  machines  might  give  us  indicators  of  our 
Cpk  (Capability  index)  not  necessarily  take  it  and  drive  it  through  each  part,  drive  it  several  times,  or  run 
multiple  simulations  and  then  compute  Cpk  numbers,  the  brute  force  method,  but  we  may  be  able  to  get 
other  metrics  out  of  it  and  do  quicker  simulations  and  estimates  of  how  capable  is  this  cell  in  making  parts, 
use  it  to  simulate  things  for  maintenance  folks.  That  was  something  that  came  up  earlier  about  showing 
how  do  you  physically  show  the  machine  move,  and  we  said,  "Well,  if  you  can  show  the  tool  tip  move, 
along  with  the  ways,  or  show  something  on  a bed,  the  way  it's  moving,  to  characterize  an  error,  would  that 
help  the  maintenance  guys?"  How  do  you  show  it?  Where  does  that  reside?  Should  it  be  on  the  same 
laptop  that  they're  collecting  data  out  in  the  shop,  or  would  it  have  to  be  off-line  on  a workstation? 

We're  trying  to  develop  tools  that  will  help  different  areas.  That's  our  role  at  the  Tech  Center.  But  the 
data  has  to  come  in  from  somewhere,  data  has  to  be  stored  in  a unique  way  and  just  one  place.  We  don't 
want  different  sets  of  data  for  all  of  this.  That's  why  I'd  like  to  reiterate  that  let's  work  with  the  data, 
modeling  the  data,  let's  figure  out  how  to  store  it,  and  to  test  the  completeness  I think  we  need  to  ask 
people  like  we  have  here  on  the  simulation  side  taking  that  and  running  simulations  to  see  if  we're  meeting 
requirements  like  what  we  have  to  simulate  a part,  what  they  might  have  to  simulate  the  way  a machine 
moves,  and  can  we  get  indices  like  what  they  were  talking  at  TI  and  help  designers  better.  And  I think 
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that's  what  some  of  the  companies  participating  in  this  should  bring  to  the  table  and  maybe  the  software 
vendors  can  help  provide  things  like  that. 

MR.  JOHNSON:  Yes.  I think  there  probably  is  a very  logical  sequence  for  how  this  capability  needs  to 
be  developed  and  put  in  place,  and,  if  we  can  think  of  a way  of,  I guess,  joint  application  of  a plan  for  what 
should  happen  first  and  second  and  third,  I think  that's  probably  what  we  need,  a road  map  with  definable 
milestones,  and  say,  you  know,  "This  is  the  capability.  This  is  what  needs  to  be  done  first.  This  is  what 
needs  to  be  done  second.  And  maybe  there  are  some  things  that  need  to  be  done  in  parallel,"  but  setting 
out  a logical  plan  for  getting  this  capability  developed  and  deployed. 

MR.  DONMEZ:  Yes,  probably  for  an  action  item  for  us,  I mean  for  the  next  meeting,  we  would  present  to 
you  some  sort  of,  as  you  say,  3 to  5 year's  road  map  of  what  we  see  as  important  steps  in  the  application. 

MR.  JOHNSON:  I would  suggest  that  you  might  also  request  inputs  from  people  that  represent  all  those 
functions  across  that  full  spectrum  of  the  product  life  cycle  also.  Some  people  may  be  waiting  for  10  years 
before  they  have  the  capability  they  want,  but  at  least,  you  know,  they'll  have  an  input  as  this  goes  along. 
Hopefully  it  won't  take  that  long. 

MS.  KRULEWICH:  I just  want  to  make  one  comment  about  the  need  to  understand  the  repeatable  versus 
the  non-repeatable  components  and  understand  the  type  of  error  distributions  again,  because  it  keeps  on 
getting  brought  up.  It's  not  going  to  be  useful  to  do  this  simulation  for  one  particular  machine  because 
every  machine  is  different.  Even  within  one  machine,  it's  not  necessarily  repeatable.  But  I think  the 
power  of  having  this  database  is  the  statistics,  and  if  you  have  all  of  this  data  for  a particular  machine, 
maybe  it's  even  for  a particular  machine  through  the  time  period  of  that  machine,  plus  other  machines  of 
the  same  family,  then  you  can  understand  the  distribution  of  those  errors.  I think  that's  a really  powerful 
tool  that  we  definitely  don't  have  now.  I don't  have  as  much  experience  going  out  and  measuring  all  the 
thousands  of  machines,  but  I'm  assuming  that  for  a given  family  of  machines  you  could  do  some  type  of 
error  distribution  of  that  one  particular  machine  for  a given  factory  floor. 

MR.  CALLAGHAN:  No.  The  problem  goes  back  to  what  I mentioned  earlier.  There  are  not  a lot  of 
factories  in  this  country  that  are  using  machine  space  applications. 

MS.  KRULEWICH:  That  doesn't  matter  though. 

MR.  CALLAHAN:  Yes  it  does,  because  the  operators  intervene.  The  operator  is  correcting  for  the  real- 
time errors,  he's  correcting  for  the  geometry  errors. 

MS.  KRULEWICH:  That's  still  okay  though  because,  let's  just  say  for  a particular  factory  floor,  the 
distribution  of  the  errors  from  one  machine  to  another  on  a factory  floor  is  a uniform  distribution.  It  could 
be  anywhere  from  -20  to  +20  micrometers  of  error,  and  it's  a uniform  distribution  and  that  is  a useful  piece 
of  information. 

MR.  CALLAGHAN:  Not  without  knowing  what  the  skill  levels  of  the  operators  are.  You  won't  have 
enough  data  to  make  that  assessment. 

MS.  KRULEWICH:  You  need  enough  data.  I mean,  you  can't  make  that  assessment  successfully  if  you 
have  three  pieces  of  data.  But,  if  you  have  a lot  of  data,  over  a long  period  of  time--  Say  you  have  five 
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years  of  data  on  this  factory  floor— they've  had  operators  come  in  and  out  and  you  have  enough  statistical 
data— you  can  statistically  make  some  conclusion  about  the  distribution  of  errors  on  that  particular  machine 
and,  knowing  the  distribution,  you  can  put  confidence  intervals  around  the  final  accuracy  of  a part.  I'm 
still  thinking  of  the  part,  not  from  a maintenance  point  of  view,  but  from  the  point  of  view  of  the  part  you 
can  put  accuracy  limits  around.  In  this  factory  you  believe  that  this  type  of  machine  can  make  parts  with 
plus  or  minus  this  accuracy  based  on  all  the  statistical  information.  We  need  to  know  the  distribution  of 
the  errors  and  the  whole  range.  I think  that  an  historical  database,  whether  it's  at  one  company  or  it's  a 
national  repository,  would  be  very  useful  for  that  purpose. 

MR.  BISHOP:  I agree  with  you  fully.  That's  the  direction  we're  trying  to  go  because,  if  I've  got  17 
machines  and  one  of  them,  or  two,  or  three  of  them,  are  performing  way  out  of  their  range  we  know  we 
can't  get  in  there  and  physically  alter  those  machines.  But,  I also  tend  to  believe  that  some  of  that  would 
be  competitively  sensitive  information  and  I'm  pretty  sure  our  company  would  not  be  willing  to  divulge 
that,  or  other  companies  as  well.  But  the  idea  is  very  sound.  I agree  with  that.  And  that's  what  we're 
trying  to  do. 

MR.  ESTERLING:  From  the  statistics  point  of  view,  I suggest  we  have  a relatively  skewed  audience  here 
in  terms  of  people  who  are  paying  attention  to  B5.54  and  using  the  services  of  IQL  and  API  and  all  the 
others.  All  our  companies  aren't.  If  you  went  to  a given  company  and  said,  "Okay,  you  don't  know  what 
your  machine  tool  characteristics  are,  but  here,  on  average,  is  how  that  machine  might  be  behaving,  and 
here  is  how  it's  going  to  behave  in  your  shop,"  should  you,  in  fact,  be  concerned  about  standards?  Should 
you  be  concerned  about  calibrating  this  machine  tool  and  whatever?  That's,  again,  the  "what  if'  scenario 
that  you  can  play  with  software,  again  to  drive  home  to  management  just  the  importance  of  the  kind  of 
calibration  that  you  guys  are  doing  at  Boeing  and  you're  doing  at  GE,  that  a whole  lot  of  other  companies 
maybe  aren't  doing. 

MR.  CHANDRASEKHARAN:  Buzz,  you  bring  up  a good  point  about  the  operator  being  that  important. 
You  can  sell  that  to  management,  saying  that  you're  taking  the  operator  out  of  the  loop.  For  a company  like 
ours,  what  we've  gone  through  in  the  last  three  years,  and  what  Boeing  has  probably  been  through,  you  can 
be  more  consistent  without  the  operator.  Machines  have  helped  us  do  that  recently.  When  I set  a machine 
up  in  the  south,  when  I set  it  up  out  of  the  country,  anywhere,  if  I can  show  that  it's  purely  a 
characterization  of  the  machine  that  is  going  to  affect  what  I'm  making  out,  it  would  mean  a big  sale. 

That's  really  useful  stuff  for  us  and  we  don't  know  how  to  do  that  yet  because  there  is  a lot  of  operator 
intervention.  We  keep  hearing  from  our  cutting  tool  suppliers  that  what  they  do  in  Japan  is,  once  they  put 
the  process  out,  the  controller  is  not  accessible  to  the  operator.  They  cannot  change  feeds  and  speeds;  the 
overrides  are  completely  locked.  You  go  to  our  plants,  that's  where  the  operators'  hands  are,  on  the 
override.  We  cannot  get  our  specs  because  we  don't  know  how  far  down  or  up  he  has  tweaked  the 
controllers.  A lot  of  it  is  good  because  a lot  of  our  operators  are  very  good,  very  well  trained,  and  they  put 
good  parts  out.  I'm  not  saying  that  it's  all  bad  stuff.  But  that's  a problem  because  the  new  guys  coming  in 
don’t  have  that  training  and  they  don't  have  the  ramp-up  time.  So,  it's  very  useful  if  we  can  take  them  out 
of  the  loop  and  know  truly  what  is  the  capability  of  that  machine  in  making  the  kind  of  parts  that  we  have 
to  make. 

MR.  CALLAGHAN:  It  would  work  if  we  can  substitute,  somehow,  that  knowledge  base  that  they've 
acquired,  for  that  particular  machine  into  the  configuration  of  the  controller  some  way.  But,  when  you 
can't  do  that,  in  the  absence  of  that.  I'll  take  a good  operator  any  day  because  we've  got  a machine  that  you 
can't  afford  the  maintenance  necessarily.  So  the  operator  is  the  next  link  that  enables  us  to  produce  good 
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parts  off  a machine  that  might  be  necessary  for  full  retrofit  or  something  and  would  cost  a lot  of  time, 
down-time,  and  money. 

MR.  HEMERLE:  We  will  not  make  another  automated  factory. 

MR.  ESTERLING:  Replacement  of  good  operators  just  is  not  going  to  happen.  I think  what  you  might 
want  to  do  is  to  put  more  power  in  the  hands  of  the  operators  themselves,  give  them  more  flexibility  in 
terms  of  what  they  can  do,  and  that's  certainly  what  the  controller  people  are  trying  to  do  is  put  more 
intelligence  down  on  the  shop  floor  and  take  advantage  of  what  these  guys  already  have  and  leverage  that. 

MR.  MA:  You  have  software  that  can  compute  the  error?  If  I give  you  the  error,  can  you  plot,  like  a 
volumetric  error,  like  a 3-D,  just  purely  the  error? 

MR.  ESTERLING:  We've  done  that  for  turning,  for  his  NIST  folks,  but  Chris,  I don't  think  any  of  our 
companies  have  addressed  this  in  terms  of  the  general  sort  of  situation.  It's  a different  niche.  Our  niche 
has  been  CNC  programmers,  to  sort  of  find  geometric  errors  for  an  ideal  machine  tool.  This  business  of 
now  modeling  errors  and  talking  about  it  is  something  that  is  going  to  require  some  rethinking  in  terms  of 
our  plans. 

MR.  DEFORGE:  There  is  no  button  on  the  screen  right  now  that  says,  "Import  Error  Function  Now 
Displayed."  That  doesn't  exist  yet. 

MR.  ESTERLING:  Basically,  we  got  the  ideal  part  program,  we  also  got  the  error  characteristics  of  the 
turning  machine  error  and  integrated  it  in.  We  then  displayed  the  part  in  the  machine  with  various 
amplifications  so  you  could  see  the  actual  error,  sort  of  the  tool  would  be  jumping  up  and  down,  but  also 
some  ways  to  be  able  to  measure  the  deviation  of  the  ideal  part  from  the  truly  machined  part.  But  that's 
only  been  done  for  turning. 

MR.  DONMEZ:  Any  other  thoughts  on  simulation  activities?  We  should  wrap  it  up  for  now.  So  if  I 
summarize  what  we've  all  discussed,  we  need  to  look  at,  again,  three  different  directions  of  the  simulation 
needs.  One  is  machine,  one  is  machine  overall  with  part,  and  one  is  only  part  and  the  tool.  Those  are  the 
three  different  approaches.  Even  though,  as  Vivek  said,  simulation  may  not  be  the  critical  factor  at  this 
stage,  what  we  should  be  looking  at  are  the  needs  from  those  software  components.  We  may  need  to 
modify  our  formats  and  the  structure  of  data  depending  on  what  type  of  inputs  those  software  tools  would 
require.  So,  I suggest  we  should  keep  those  in  mind. 

MR.  CHANDRASEKHARAN:  Definitely.  I didn't  mean  to  say  we  shouldn't  be  doing  simulation,  but 
what  I'm  saying  is  we  should  do  it  to  define  the  completeness  of  the  data  and  make  sure  our  definitions  are 
correct  and  we  have  adequate  information,  and  I agree  with  you  completely  on  that. 
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DISCUSSIONS  ON  HOW  TO  USE  A WEB  REPOSITORY 


MR.  DONMEZ:  We  talked  about  the  repository  yesterday.  We  showed  some  examples  and  we  talked 
about  what  type  of  data  that  we  would  put  in  it.  Basically  we  dwell  on  the  very  raw  part  of  the 
information.  Now,  the  reason  I put  this  item  here  is  to  talk  about  what  other  needs  that  we  have,  what 
analytical  tools  or  analyses  that  we  need  to  do  in  the  repository  itself,  if  any. 

As  you  saw  yesterday,  Larry  ran  a MATLAB  program  in  the  background  and  produced  some  information 
based  on  the  raw  data  provided  by  the  instrument.  How  much  of  that  kind  of  activity  we  foresee  that  we 
need  in  the  repository?  That's  what  I'd  like  to  discuss  a little  before  we  go  too  much  further  in  the 
development. 

MR.  CALLAGHAN:  I have  a suggestion.  Maybe  as  minimum,  we  should  have  the  algorithms  that  are 
necessary  to  analyze  the  data  according  to  the  existing  standards,  like  the  new  ISO  standards,  new  B5,  B89 
methods  of  analyzing  the  data. 

MR.  DONMEZ:  One  extreme  position  would  be,  for  example,  if  Don  Esterling  would  require  a functional 
representation  of  the  error,  do  we  need  to  do  all  the  fits  in  the  repository  and  provide  that  mathematical 
representation  of  that  particular  error  component  or  not?  I think  that's  an  extreme  case. 

MR.  CALLAGHAN:  It  makes  sense  though.  If  you  look  at  the  history  of  the  CMM  algorithms,  there  was 
a whole  host  of  different  ones  out  there  for  describing  different  forms  and  shapes,  most  of  which  didn't 
work,  and  it  took  like  almost  a ten  year  period  developing  a standard  algorithm  and  I think  NIST  is  a 
repository  for  those  right  now.  I think  that  makes  a lot  of  sense  to  have  that  done  in  one  place,  do  it  once, 
rather  than  have  all  the  different  vendors  develop  those  fitting  methods. 

MR.  DONMEZ:  But,  on  the  other  hand,  people  may  have  better  solutions. 

MR.  CALLAGHAN:  Yes,  they  might,  but  again,  they  went  through  an  extensive  testing  program  on  the 
algorithms  for  fitting  the  forms  for  the  CMM.  Maybe  that's  the  same  sort  of  thing  that  is  necessary  here, 
to  fit  certain  functions  to  certain  kinds  of  errors  that  we  see  in  the  data.  To  me,  with  the  size  of  the 
community  we  have,  and  the  resources  we  have,  it  doesn't  make  sense  to  have  everybody  trying  to  do  the 
same  thing,  reinvent  the  wheel. 

MR.  DONMEZ:  So,  the  sample  that  you  saw,  the  MATLAB  kind  of  mathematical  tools,  would  be  useful 
in  your  opinion  to  be  able  to  do  all  these  fittings  and  mathematical  manipulations  of  the  raw  data  that  is 
input  into  the  repository? 

MR.  MA:  There  are  mathematical  tools  in  the  area  of  technical  support.  Different  machines  have 
different  data  patterns  and  someone  will  probably  have  to  dedicate  a lot  of  their  time  to  solve  all  these  kind 
of  real  problems  and  respond  to  them. 

MR.  DONMEZ:  Those  are  sticky  issues  from  the  licencing  point  of  view.  I'm  not  too  eager  to  put  more 
mathematical  tools  into  it.  For  example,  the  licensing  issue  for  MATLAB  came  up  during  our  own 
discussions.  We  just  used  it  as  a prototyping  tool  but,  if  you  open  it  up  as  a tool  that  comes  with  the 
repository,  then  what  happens  to  the  licensing? 
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MR.  CHANDRA SEKHARAN:  I'm  a little  confused  here.  Are  we  trying  to,  at  the  end,  have  a complete 
set  of  tools,  of  software  and  things  like  that,  that  somebody  can  use  to  make  profit,  or  is  it  just  going  to  be 
something  to  validate  the  concept  on  an  experimental  basis  for  what  we  are  doing  now?  My  understanding 
is  the  latter,  so  I don't  think  this  licensing  issue  should  be  a big  thing  because  it's  sort  of  research  at  this 
point.  All  we  are  trying  at  this  point  is  to  show  that  we  can  take  this  data,  define  it  in  a certain  format, 
store  the  data  in  a certain  format,  and  prove  that  you  can  generate  error  functions,  prove  that  you  can  use  it 
to  do  simulation,  prove  that  you  can  generate  the  kinematic  motions  of  the  machine. 

MR.  DONMEZ:  Yes.  That's  certainly  our  view. 

MR.  MA:  If  you  already  set  out  rules,  and  then  later  you  find  that  some  of  the  elements  are  going  to  be 
very  costly,  then  the  rules  will  probably  have  to  change.  You  said  there  is  a potential  licensing  problem. 
You  need  to  think  about  that  earlier  so  you  can  make  use  of  that  later  on. 

MR.  DONMEZ:  The  other  alternative  would  be,  as  server  managers,  we  could  do  the  calculations  in  the 
background  and  provide  the  results  and  not  do  the  calculations  in  real-time,  and  therefore  the  users  of  the 
repository  don't  use  the  tool. 

MR.  CHANDRASEKHARAN:  Right.  In  fact,  I don't  think  I'll  be  using  that.  For  the  data  we're  collecting 
on  the  floor  we  won't  be  using  the  repository  and  the  tools  you  provide  to  analyze  the  data.  We  won't  be 
doing  that.  We  have  our  own  tools  the  way  we  do  it  today,  and  we'll  stick  with  that.  What  we'll  probably 
test  is,  if  we  are  developing  simulation  capability,  can  the  models  that  they  are  generating  feed  something 
like  that.  So  it'll  be  a trial  basis  or  an  experimental  basis,  and  so  you're  absolutely  right.  If  it  does  mean 
that  Larry  is  the  only  person  that  will  finally  send  for  the  calculations  and  put  the  results  back  up  the  next 
day,  that's  fine.  We  want  to  test  the  completeness  of  the  data,  so  we  probably  should  be  okay.  I don't 
know  about  the  rest  of  the  folks  here,  but  we  won't  be  using  it  for  doing  our  regular  calculations  or  regular 
analyses. 

MR.  DONMEZ:  The  other  use  from  the  simulation  developer's  point  of  view,  is  to  be  able  to  get  access  to 
the  layers  depending  on  their  own  complexities  and  be  automatically  generating  the  form  that  they  want  to 
put  the  data  in,  but  maybe  it's  too  early  at  this  stage,  based  on  the  discussions  earlier,  that  we  don't  know 
yet  what  simulation  tools  will  require. 

MR.  DEFORGE:  I think  what  I need  to  do  is  to  communicate  to  Larry  and  others  what  we  need  today,  to 
build  a model  today,  and  instead  of  doing  that  here.  I'll  send  you  the  information  that  I require  in  order  to 
build  a mill  or  to  build  a lathe.  Then  at  some  point  I think  it  would  be  valuable  to  take  a look  at  these 
simulation  tools  and  see  the  kinds  of  information  we're  able  to  get  from  them?  I'm  wondering  if  that 
would  be  an  appropriate  step  at  the  next  meeting 

MR.  DONMEZ:  Should  we  allocate  some  time  to  do  some  sort  of  demonstration,  like  your  system  as  of 
now,  what  can  it  provide,  and  what  in  the  near  future  can  it  provide?  We  can  provide  you  some  data  and 
then  you  can  play  with  it  and  come  up  with  some  ideas. 

MR.  DEFORGE:  Absolutely.  We'd  be  willing  to  do  that.  I kind  of  envision,  if  this  is  where  we're  going, 
I'd  like  to  be  able  to  call  up  the  database  and  say,  I've  got  this  particular  machine  tool  and  it's  got  its 
fundamental  description  which  comes  down  to  this  document  here,  and,  like  any  other  machine  tool,  you 
can't  do  anything  else.  We  can't  look  at  some  of  these  other  issues  until  we  have  the  basics.  How  is  this 
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machine  supposed  to  be  assembled?  How  does  it  move?  So,  until  we  get  that  information  we  can't  even 
deal  with  any  of  these  other  issues.  I think  that's  the  first  step.  If  we  were  to  look  at  a web  screen  that 
says,  "Basic  Machine  Components,"  and  you  click  on  that  button  and  it  gives  you  all  that  fundamental  type 
of  information  to  help  us  build  a model  quickly.  If  you  had  another  button  that  says,  "Now  Let's  Calibrate 
This  Machine  Tool,"  we  could  try  to  bring  the  virtual  world  and  the  reality  world  a little  bit  closer 
together.  What  kind  of  information  do  we  need  to  do  that  and  what  can  we  use  today  and  what  can't  we 
use  today?  I think  that  has  to  be  defined  so  that  we  get  back  not  just  what  we  need,  but  what  we're  capable 
of  dealing  with.  That  then  becomes  of  value  to  us  and,  I think,  to  our  customers  as  well. 

MR.  ESTERLING:  Chris'  company  looks  at  things  on  different  levels  than  we  do.  They  deal  with  more 
of  an  overall  sort  of  machine  tool  process  modeling,  as  well  as  the  micro  sort  of  modeling,  whereas  we're 
more  myopic  and  look  more  at  the  material  removal  level,  and  that's  our  focus,  our  specialty.  So  our  needs 
are  quite  different  in  terms  of  the  overall  sort  of  machine  tool  set-up,  not  where  all  the  bolts  are  but  what 
we  really  want  to  know  is  what  is  the  cutter  doing,  what  is  the  spindle  doing,  what  is  the  holder  doing,  and, 
where  is  it  going.  Those  are  the  sorts  of  things  that  we  need  within  our  modeling  sort  of  structure. 

MS.  KRULEWICH:  I have  a question.  Maybe  this  should  be  focused  towards  Boeing  too  to  see  what 
industry's  interest  in  this  is.  Is  the  purpose  of  the  repository  just  to  create  a place  to  store  this  data  so  that 
all  these  other  packages  can  easily  store  to  and  retrieve,  or  is  it  more  of  even  a larger  vision,  that  you 
would  actually  put  software  tools  in  there  also? 

One  software  tool  is  the  statistical  analysis  of  errors,  but  that's  the  one  tool  that  does  not  exist  and  can  only 
exist  on  a system  that  has  this  large  amount  of  data  which  doesn't  exist  now.  But  it  seems  to  me  it  would 
be  useful  for  it  to  have  the  ability  to  take  this  group  of  data  and  do  some  statistical  analysis  on.  I don't 
know  if  it  would  be  on  a particular  parametric  error  or  on  the  whole  volumetric  error,  but  to  do  something 
like  that  could  be  useful.  But  it  seems  like  now  there  are  all  these  other  packages  that  people  are  pretty  set 
on  using  and  the  main  thing  for  the  database  would  be  to  have  the  ability  to  access,  retrieve  and  store  to 
the  database. 

MR.  DONMEZ:  If  you  remember  from  my  earlier  presentation  yesterday,  our  ultimate  goal  is  to  be  able  to 
enable  this  virtual  machining/virtual  inspection  environment.  But,  in  order  to  get  there,  this  repository  is 
an  essential  tool  because  of  two  reasons:  one,  in  immediate  industrial  use  those  companies  need  to  get  the 
information  from  their  capacities  and  capabilities;  and  the  other  important  thing  is  from  the  research 
perspective,  as  you  mentioned,  to  do  analysis  on  these  healthy  data  and  come  up  with  more  robust  models 
than  we  have  today,  and  that  includes  some  statistical  analysis  into  the  variation  of  machine-to-machine 
behavior.  So,  all  these  things  will  be  possible  if  we  have  a repository  which  has  unambiguous,  healthy 
data  on  a variety  of  different  machine  tools. 

MR.  CALLAGHAN:  Alkan,  I thought  we  agreed  yesterday  that  this  is  strictly  an  experimental  testbed  and 
Boeing  is  probably  not  going  to  contribute  any  data  to  that.  I probably  will,  because  I want  to  see  how  it 
works.  Cat  is  not  going  to  contribute. 

MR.  CHANDRA SEKHARAN:  We  will  contribute  sample  data.  One  or  two.  We're  not  going  to  keep 
putting  data  into  the  repository. 

MS.  McMILLAN:  We'd  certainly  like  to  give  guidance,  input,  be  able  to  ask  questions. 
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MR.  CHANDRASEKHARAN:  For  instance,  if  we  think  the  data  definitions  may  not  work  on  a certain 
type  of  machine  data  that  we  collected,  we'll  probably  test  it  by  putting  that  data  in  and  maybe  take  it  back 
out,  or  put  it  back  in  and  let  somebody  else  use  it.  So,  if  you  have  some  questions  in  testing  the 
completeness  or  doing  a statistical  fit  on  different  kinds  of  machines  you  can  probably  work  with  the 
group  and  see  if  there  is  similar  data  that  you  can  get  and  do  analysis  on,  or  something  like  that.  But  it's 
not  a repository  where  we're  going  to  keep  feeding  in  data.  We're  not  committing  to  that. 

MR.  DONMEZ:  That  is  absolutely  true,  but  we  also  have  to  keep  in  mind  that  the  power  of  this  type  of 
repository  is  the  amount  of  data  that  we  can  put  in  and  get  information  from  that.  So,  one  or  two  machines 
is  not  going  to  be  enough;  we  have  to  have  a lot  of  machines,  not  necessarily  from  only  one  company,  but 
from  all  over  the  country  we  need  to  have  lots  of  different  types  of  machines. 

MS.  McMILLAN:  Maybe  if  we  called  it  a "Test"  repository,  so  that  people  didn't  think  this  thing  was 
going  to  start  growing  and  keep  growing.  I see  it  as  a good  test  repository.  If  we  could,  in  industry,  start 
talking  at  least  the  same  language,  which  gets  back  to  your  data  dictionary,  that's  a start  for  being  able  to 
transfer  data  back  and  forth.  If  I've  got  the  same  machines  that  Caterpillar  has  got  and  I do  want  to  do 
some  comparison  on  a particular  type  of  machine,  I can  talk  to  that  person  and  possibly  exchange  data  at 
some  point,  because  we  talk  the  same  language.  And  maybe  with  that  data  structure  I could  compare  it 
against  the  data  structure  that  I currently  have  and  see  what  I'm  missing  and  see  what  I'm  not.  That's  what 
I would  want  to  use  that  for. 

MR.  CALLAGHAN:  Back  to  your  statistical  analysis,  I agree  with  that  and  we  plan  on  doing  that  also. 

MS.  KRULEWICH:  But  that's  a later  step. 

MR.  CALLAGHAN:  Right.  We  need  to  get  the  database  in  place  and  the  fixturing  in  place  and  then 
analysis. 

MS.  KRULEWICH:  Will  the  analysis  reside  on  the  same,  or  will  it  be  a completely  separate  system?  Will 
it  reside  on  the  same  system? 

MS.  McMILLAN:  In  ours  it  would  probably  reside  within  it. 

MS.  KRULEWICH:  Yes,  because  I was  just  thinking  back  to  the  question  that  you  raised  of  whether  you 
should  be  providing  software  tools  or  not.  It  sounds  like  most  of  the  people  that  want  to  use  this  database, 
the  main  interest  is  just  to  see  if  they  could  access  and  retrieve,  not  necessarily  do  analysis. 

MR.  CALLAGHAN:  My  hope  is,  too,  that  we  learn  as  we  go.  Let's  say  we  have  a database  in  place  and 
we've  decided  what  all  the  dictionary  definitions  are,  we've  got  some  data,  we've  tested  it,  the  next  phase  is 
analysis,  and  I'd  like  to  know  what  Caterpillar  does  with  it.  How  do  I statistically  handle  my  data  and  how 
does  he  handle  his?  So  you  can  communicate  back  and  forth. 

MR.  CHANDRASEKflARAN:  Yes.  We  will  do  that. 

MR.  CALLAGHAN:  It's  more  than  the  actual  specifics,  how  do  you  do  it  and  how  much  do  you  do.  I 
have  an  experimental  question  for  that.  Once  you  get  the  data,  how  are  you  going  to  use  the  data  most 
effectively? 
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MR.  CHANDRASEKHARAN:  And  we'll  contribute  as  much  data  as  required  to  meet  their  needs  and  our 
needs  and  do  analysis  of  that  type  to  keep  the  momentum  going.  That's  our  goal.  We  have  a few  priorities 
on  how  we  want  to  analyze  the  data.  Some  of  it  is  statistical  analysis,  some  of  it  is  just  to  have  access  and 
retrieval  and  use  it  for  simulations  of  different  types,  and  feedback  information  to  designers.  But,  we  need 
some  place  to  test  it.  If  we  start  trying  to  define  this  thing  ourselves,  and  try  and  put  some  data  in,  we  find 
our  limitations  in  our  resources  in  defining  the  data,  limitations  on  the  amount  of  data  we  had.  If  you  can 
leverage  things  like  this  and  call  it  "machine  A,  B,  C,  from  Company  DEF,"  that's  all  we  need. 

MR.  MA:  The  problem  is  that  we're  not  measuring  a machine  like  you're  measuring  the  part.  You 
measure  the  part  may  be  thousands  a day.  You're  measuring  a machine  may  be  every  month.  Actually 
your  machine  bed  probably  already  has  changed,  so  your  model  now  will  be  quite  different. 

On  the  other  hand,  when  we  send  out  data  to  this  database,  do  you  want  the  clean  data,  or  do  you  want  us 
just  dump  whatever  format  we  have.  Because,  that's  quite  a lot  of  data  entry  work. 

MR.  DONMEZ:  Yesterday  Larry  promised  that  as  long  as  you  provide  the  full  format  of  your  data  he  will 
take  it. 

MR.  WELSCH:  We  need  the  specification  though.  That  is  absolutely  clear.  Now,  obviously,  if  you're 
taking  it  from  the  same  types  of  data  that  I've  seen,  then  I think  it's  reasonably  straightforward,  but  the  data 
dictionary,  as  we  keep  saying,  is  a major  issue,. 

MS.  McMILLAN:  And  it's  a really  good  first  step,  don't  you  think? 

MR.  WELSCH:  Yes. 

MR.  CALLAGHAN:  I hope  too  that  when  you  get  this  data  dictionary  in  place  and  we  can  come  to  some 
agreement,  that  would  start  influencing  the  providers  of  software  to  move  in  that  direction.  We  don’t  want 
to  create  little  programs  to  search  and  parse  the  data  individually.  I'd  like  for  us  to  somehow  come  up 
some  standard  methodologies  and  some  standard  representations  for  data  where  we  have  easier  access  to  it 
than  we  currently  do. 

MR.  WELSCH:  That's  where  we  want  to  head. 

MR.  CALLAGHAN:  You  can  do  that  job  and  we  can  do  that  job,  but  I don't  like  doing  that  if  I don't  have 
to.  If  that's  one  of  the  outcomes  of  this  meeting,  I would  hope  that  we  could  come  to  that  eventually. 

MR.  WELSCH:  Initially,  we're  going  to  set  up  a web  page  with  a proposed  data  dictionary  and  start 
collecting  everybody's  comments  on  that.  That  will  also  be  probably  one  of  the  early  discussion  topics  on 
our  mailing  list  that  we'll  be  sending  out  in  the  very  near  future  and  trying  to  solicit  everybody's 
comments. 

At  this  point  in  time,  for  data  similar  to  the  types  of  data  that  I have  seen,  similar  to  the  types  of 
specification,  where  there  is  a —and  I'm  going  to  use  a computer  science  expression—  well  defined  regular 
grammar  to  it,  or  a very  well  defined  format,  getting  it  into  some  type  of  form  is  reasonably 
straightforward  in  the  sense  of  writing  a program  that  will  parse  it.  Now,  as  you  write  more  of  these, 
keeping  track  of  all  the  different  things  starts  to  become  a tremendous  issue. 
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MR.  CALLAGHAN:  All  the  versions  that  you  have  to  keep  track  of? 

MR.  WELSCH:  Yes.  But  that  gets  us  started,  and  hopefully,  once  the  usefulness  of  the  repository 
becomes  clear,  we'll  be  able  to  draw  those  things  that  are  simplest,  or  most  straightforward,  or  that  comes 
closest  to  what  people  actually  have,  and  start  encouraging  people  to  then  deliver  it  in  a limited  set  of 
forms.  But,  right  now  we  want  to  just  get  started,  so,  we'll  take  it  on  ourselves  to  take  some  of  these 
specifications  and  get  the  data  and  get  it  in.  I don't  know  another  way  to  really  get  it  started  because,  in  a 
sense,  if  we  define  a very  complex  format  and  give  it  to  everybody  and  say,  "Here,  this  is  the  only  way 
we'll  accept  it,"  nobody  will  build  to  it.  The  problem  I'm  faced  with  is  how  robust  can  we  make  these 
things. 

MR.  CHANDRASEKHARAN:  Debbie,  you  talked  about  something  else.  You  talked  about  sign 
conventions  and  the  way  we  store  data  and  things  like  that.  If,  indeed,  the  way  Hans  Soons  is  defining  the 
data  is  complete,  no  matter  how  you  submit  the  data,  it  should  be  able  to  have  enough  information.  You 
can  parse  it  and  store  it  uniquely,  so  anybody  else  can  go  and  recreate  it.  By  different  people  submitting 
data— obviously  Boeing  is  probably  collecting  it  and  storing  it  differently,  you're  doing  it  differently,  we're 
probably  doing  it  somewhat  differently  and  different  vendors  of  the  hardware  are  doing  it  differently— 
that,  in  itself,  is  a test  for  communicating  correctly.  Then,  you  can  look  at  the  more  difficult  stuff  of  trying 
to  get  statistical  metrics  out,  trying  to  get  other  things  out,  all  the  other  stuff  that  we  talked  about. 

MR.  MA:  I think  you  need  quite  a model  of  a machine,  what  type  of  machine,  what  kind  you  have,  so  that 
you  have  the  same  program,  the  same  language. 

MR.  CALLAGHAN:  Just  starting  up  with  two,  I don't  think,  would  be  necessarily  meaningful  at  this  time 
until  we  define  what  those  rules  are  and  what  that  data  dictionary  looks  like.  I don't  know  that  it  would  be 
beneficial  until  that  has  been  established. 

MR.  WELSCH:  I think  it's  a chicken  and  egg  problem.  In  a sense,  the  development  of  the  data  dictionary, 
in  my  mind,  is  partly  driven  by  what's  in  the  data  today.  Top-down  design  is  great  when  you  know  what 
the  end  product  is  going  to  be.  Bottom-up  design  is  great  when  you  don't  have  any  idea  what  you're  going 
to  build.  Usually  most  designs  are  from  the  inside  out.  You  do  a little  bit  here,  you  do  a little  bit  there, 
and  eventually  you  develop  a very  nice  solid  design  from  the  top  to  the  bottom  as  long  as  you  are  willing 
to  be  flexible. 

MR.  SOONS:  I think  there  might  be  a slight  problem  with  that  approach.  Although  I would  very  much 
like  to  receive  samples  of  data,  part  of  the  information  that  we  are  really  interested  in  is  in  Loyd  Bishop's 
notebook.  What  extra  information  does  he  write  down  about  a test  besides,  just  say,  the  data  file.  To  test 
the  completeness  of  the  data  dictionary  that  information  is  essential,  and  I'm  wondering  if  you  are  willing 
to  part  with  that  information  or  that  you  want  to  wait  before  there  is  a dictionary  and  see  if  you  can 
translate  it  into  that  dictionary. 

MR.  BISHOP:  Either  way,  from  an  experimental  standpoint  I don't  think  there  is  any  problem  with  that. 
That's  nothing  proprietary  at  all. 

MR.  CALLAGHAN:  Larry,  you're  saying,  almost,  that  if  we  give  you  the  data,  then  you'll  figure  out  the 
dictionary  for  us,  based  on  the  inputs.  Is  that  what  I understand? 
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MR.  WELSCH:  We'll  try.  We'll  take  a stab  at  it.  And  it'll  probably  be  wrong,  but  it  might  be  very  close. 

MR.  CALLAGHAN:  I think  Hans  has  already  got  a really  good  start  here.  We've  already  done  the  actual 
field  structures  and  everything  is  based  on  the  software  that  we've  been  using  currently.  We  know  what 
the  size  of  the  fields  are,  the  number  of  characters  and  everything,  for  all  the  different  fields  that  we're 
using.  We  have  some  of  that  information  and  I don't  think  any  of  that  is  proprietary;  so  we  could  share 
any  of  that  we've  already  accumulated  if  that  would  be  of  value.  That  would  help  it  go  little  faster,  a little 
easier,  than  you  having  to  read  and  decide  how  many  characters  are  in  each  data  set. 

MR.  WELSCH:  That’s  exactly  the  type  of  information  that  would  make  it  go  very  fast. 

MR.  CALLAGHAN:  For  the  kind  of  data  that  Hans  was  discussing,  we  built  tables.  I hate  the  keyboard 
entry  of  anything.  So,  what  we're  trying  to  do  is  categorize  all  the  different  kinds  of  inputs  and  make  them 
in  pull-down  lists.  But,  you  can't  sort  on  text  very  well.  When  they  just  put  a paragraph  in  there  it's  really 
hard  to  know,  from  a computer  standpoint,  what  that  means.  So  we've  taken  some  effort  to  do  the  other 
direction  where  we  actually  have  fields  and  we  categorize  those  elements. 

MR.  WELSCH:  I think  sharing  that  with  this  group  and  with  us  is  extremely  helpful  in  the  sense  of 
accelerating  this  process. 

MR.  CALLAGHAN:  We  have  it  conceptualized.  We  haven't  yet  taken  the  data  on  the  tool.  We  have  to 
get  out  to  Loyd  and  people  like  him  to  do  that. 

MR.  BISHOP:  Do  you  have  the  front  ends  yet? 

MR.  CALLAGHAN:  We've  got  the  table  out  there.  We  don't  have  the  data  input  screens.  They're  in  the 
process  of  being  developed.  They're  not  quite  that  far  along  yet.  But  we  know  element-wise  what  we 
need  to  do.  We  need  to  test  it  and  verify  it.  A lot  of  things  have  to  happen. 

MR.  WELSCH:  One  of  the  possible  ways  of  us  working  with  you  is  to  take  that  element  data,  put  some 
screens  on  it  through  an  HTML  basis,  through  the  web,  and  broaden  your  test  to  a larger  community  of 
people  so  we  can  get  a more  accurate  evaluation. 

MR.  CALLAGHAN:  We  probably  need  to.  We  have  discussed  it,  but  whether  or  not  this  is  going  to  be 
an  open-ended  web  page  or  a restricted  application,  we're  just  wondering  what  the  participation  level 
would  be  based  on  that. 

MR.  WELSCH:  I don't  think  we  could  stand  open-ended  web  page. 

MR.  CALLAGHAN:  So  you're  saying  it's  going  to  be  limited,  hopefully? 

MR.  BLOMQUIST:  That's  what  we  decided  yesterday,  it  was  going  to  be  a limited  number. 

MR.  CALLAGHAN:  Limited  to  people  who  have  records  to  give.  We  have  to  verify  that  we  can  do  that, 
but  I don't  see  a problem. 

MR.  DONMEZ:  I suggest  that  we  would  iron  out  the  details  of  this  type  of  thing  later  on,  but  it's  clearly 
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necessary  that  we  need  to  start  on  the  data  dictionary,  and  one  of  the  things  that  we  can  use  as  a starting 
point  is  the  existing  standards.  B5.54  has  a glossary  and  definitions,  ISO  230-1  has  definitions.  I was  just 
talking  to  Ray  McClure  earlier,  we  may  be  able  to  put  them  on  the  web  site  if  we  can  get  some  proper 
permission  from  ANSI.  Ray  indicated  that  if  you  download  it  you  pay,  but  if  you  don't  download  it,  you 
look  at  it,  you  don't  have  to  pay,  so  that  might  be  the  way  to  get  around  that  problem.  I will  investigate  it. 
If  possible,  will  put  those  on  the  web  site. 
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DISCUSSIONS  ON  REPRESENTATIONS  OF  MACHINED  PART  GEOMETRY 


MR.  DONMEZ:  Our  last  item  on  the  agenda  is  the  discussion  on  representation  of  machined  part 
geometry,  which  is  related  to  the  simulation  tools  as  well  as  virtual  inspection  programs.  We  haven't 
talked  about  virtual  inspection  in  this  meeting  but,  as  I mentioned  yesterday,  our  long  term  goal  includes 
virtual  inspection  as  well  as  virtual  machining.  So,  we  need  to  start  thinking  about  how  we  are  going  to 
represent  the  machined  parts  in  the  computer  domain.  For  now,  the  best  thing  would  be  to  measure  as 
much  datapoints  as  possible  on  the  part  and  then  keep  all  this  information  as  raw  data.  But  there  are  other 
alternatives.  We  can  have  B splines,  we  can  have  polynomial  fits,  we  can  have  all  sorts  of  other 
mathematical  tools  to  represent  features  on  the  part.  There  are  pros  and  cons  in  all  aspects  of 
representation,  so  I'd  like  to  initiate  a discussion,  so  that  we  can  think  about  it  after  we  go  back.  We'll 
have  more  detailed  discussions  in  the  next  meeting. 

MR.  ESTERLING:  I'd  suggest  that  if  you  tried  to  maintain  splined  data  you'll  be  overwhelmed.  Each  of 
the  companies  that  does  a simulation  has  their  own  internal  modeling  system  and  each  has  its  own 
individual  strengths  and  weaknesses.  Chris  Deforge  and  I both  have  a solid  modeling  format  underlying 
our  structure,  rather  different  in  terms  of  our  approach.  The  advantage  of  a solid  model  system  is  it's 
complete,  robust,  and  it's  got  what  you  need.  The  disadvantages  will  be  the  kind  of  accuracy  you  need  to 
maintain  the  model.  Your  ideal  part  may  have  B splines,  but  your  actual  part  has  all  kinds  of  funky 
features  in  it  which  aren't  amenable  to  a standard  sort  of  CAD  type  modeling  structure.  That's  why,  for 
example,  our  company  developed  a proprietary  internal  modeling  system  to  handle  that. 

But  I think,  if  you  try  to  go  to  point  data,  you're  going  to  have  several  problems.  One  is  an  overwhelming 
amount  of  data,  much  of  which  is  not  really  required.  You  are  also  going  to  have  a problem  of  accuracy. 

If  you  try  to  trade  off  that  point  set  with  a sparser  set  because  you  don't  want  to  have  all  that  data,  then  you 
lose  accuracy  between  the  sparse  points.  The  third  problem  you  have  with  point  data  is  feature  formation. 
Depending  upon  the  kind  of  modeling  structure  you're  using,  if  you  could  maintain  feature  data,  and  by 
"feature"  I mean  relatively  simple  features— pockets,  holes,  edges,  comers— that's  the  information  that  you 
might  want  to  look  into  and  have  available  in  your  system.  But  if  you  have  only  point  data  you  don't  have 
that  information. 

MR.  DONMEZ:  You  have  an  internal  representation  which  is  proprietary.  If  we  are  going  to  provide  the 
information  on  the  part  to  another  module,  which  will  do  the  virtual  inspection,  that  a company  like  ICAM 
is  developing,  how  are  you  going  to  give  that  information  to  the  other  module? 

MR.  ESTERLING:  We  are  market  driven,  like  everybody  else  in  this,  and  we  developed  a tool  kit  which 
lets  folks  get  in  and  out  of  our  model  to  access  different  parts  of  our  system.  We  started  out  with  a 
traditional  CAD  type  solid  modeling  systems.  We  went  to  a proprietary  system  because  traditional  CAD 
for  solid  modeling  didn't  work  in  this  kind  of  environment,  at  least  it  didn't  work  for  us.  But  that  still 
means  that  we  needed  to  talk  to  the  rest  of  the  world,  so  we  needed  a way  to  export  our  system  into  a more 
traditional  type  CAD  environment  and  this  is  something  which  we  sort  of  have  now  and  it’s  under 
development  and  will  be  available  very  shortly  as  part  of  this  tool  kit. 

So  we're  not  closed  in  the  sense  of  communicating  with  other  modules,  but  it's  closed  because  we  had  to 
develop  our  own.  But  we  still  have  to  talk  to  the  rest  of  the  world,  both  import  and  export.  We  need  to 
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import  CAD  type  data  for  stock,  as  design  data,  and  we  need  to  export  in  terms  to  be  able  to  say,  "Okay, 
what's  the  next  step?  Do  you  want  to  use  this  for  inspection?  Do  you  want  to  use  it  for  assembly,  or 
whatever?" 

MR.  DEFORGE:  We  basically  have  the  same  type  of  approach,  where  we  have  direct  CAD  interfaces,  as 
well  as  standard  CAD  translators  for  exporting  part  geometry  and  importing  part  geometry  as  well.  Our 
machining  process  does  work  with  a proprietary  CAD  system,  for  lack  of  a better  term,  and  that  really 
goes  to  the  core  of  the  software.  So  I don't  see  us  changing  that.  The  best  we  could  do  is  make  sure  that 
we  do  make  available  these  CAD  interfaces  and  CAD  translators. 

MR.  DONMEZ:  When  you  export  your  data,  are  your  models  basically  nominal  part  models? 

MR.  DEFORGE:  That's  correct. 

MR.  DONMEZ:  But  when  you  have  this  type  of  simulation  capability  you  will  have  non-uniformities  in 
these  surfaces.  Are  you  currently  capable  of  exporting  such  geometries? 

MR.  DEFORGE:  Yes,  within  reason.  You  have  to  look  at  issues  of  accuracy  and  extent.  If  you  want  a 
simulation  that  takes  a process  that  would  normally  take,  let's  say,  8 hours  on  a machine  tool  and  make  it 
happen  in  a few  minutes,  which  seems  to  be  the  desire,  in  essence,  you're  going  to  sacrifice  accuracy  in 
the  rendering  of  the  part  in  today's  technology. 

MR.  DONMEZ:  As  a user  of  the  output  can  I specify  the  spatial  frequency  of  the  data  when  you  export 
the  data,  for  example? 

MR.  ESTERLING:  Again,  Chris  and  I come  from  different  modeling  methods  and  different  sort  of 
spectra.  In  fact,  we're  doing  today  something  that  takes  8 hours  in  a machine  tool  in  a few  minutes  on  a 
Pentium  at  the  accuracy  that  you  need  at  a shop  floor  for  the  nominal  part.  That's  where  we  are  right  now. 
You  know,  there  are  things  that  we  need  to  do  to  our  product  to  be  able  to  sort  of  handle  the  kind  of 
waviness,  the  error  analysis,  that  we  discussed  here,  but  it's  within  the  same  sort  of  modeling  structure  we 
have  right  now.  It's  an  achievable  goal. 

I suspect  Chris  and  I look  at  the  same  perspective  in  the  sense  that  when  you  give  us  a tool  pack  with 
errors  in  it,  we  consider  the  desire  to  know  what  the  tool  sweep  is  , where  it’s  going  and  we  then  model  it. 
We  have  to  model  it  in  different  ways  and  different  methods,  each  with  their  individual  strengths  and 
weaknesses. 

MR.  DONMEZ:  Yes  that's  true,  but,  in  the  end,  what  I'm  interested  in  is  getting  that  information  out  from 
your  module  and  putting  it  into  another  module  where  I can  test  my  inspection  algorithms.  In  order  to  do 
that,  sometimes  I may  need  very  finely  spaced  points,  though  sometimes  not.  I need  to  be  able  to  specify 
that  kind  of  spatial  frequency  to  you. 

MR.  ESTERLING:  It  leads  back  to  the  point  I made  at  the  start  regarding  speed,  accuracy  and  the  size  of 
the  part.  But  for  a nominal  sized  part  and  with  a reasonable  horsepower  in  a reasonable  period  of  time 
you're  putting  very  heavy  demands  on  the  accuracy  of  the  model.  That's  this  triangle  that  Chris  was 
talking  about,  and  I'm  saying  for  nominal  parts,  without  the  errors  involved,  we're  there  today. 
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MR.  MA:  Do  you  have  any  CMM  simulation  software? 

MR.  DEFORGE:  Virtual  inspection  is  something  that  I don't  think  puts  us  in  a position  to  claim  we  can 
do,  to  create  a part  that  we  can  say,  from  a model,  that  these  are  your  quality  control  issues.  We're  not 
there  yet. 

MR.  ESTERLING:  We  cannot.  It's  a product  we'd  like  to  manufacture.  I mean,  there  are  two  aspects 
here.  One  aspect  is  to  model  the  CMM  process  itself.  And  we  don't  do  that.  I have  to  tell  you  on  my  top 
10  list  of  things  to  do  it's  probably  not  in  that  top  10  because  we  have  lots  of  other  things  we  still  need  to 
do  within  the  CNC  environment,  as  opposed  to  the  CMM  environment.  But  to  be  able  to  import,  to  get 
back  to  what  Alkan  was  asking  about,  to  import  a CAD  model,  a CAD  surface,  as  Deneb  does,  I believe  as 
well,  and  then  be  able  to  give  you  a profile  as  to  how  the  as-machine  part  deviates  in  terms  of  gouges,  in 
terms  of  excess  material,  is  something  that  several  vendors  offer.  If  that's  what  you  mean  by  CMM,  yes. 
We  also  offer— and  by  "we,"  I mean,  generically  across  the  industry— ways  to  do  something  like  a CMM 
probe,  you  can  point  to  a given  spot  on  the  part  and  given  the  CAD  data,  get  back  your  coordinates  of  the 
point  as  well  as  all  the  surface  normal  deviation  for  the  CAD  data  as  well.  You  know,  that's  available  in 
the  industry  today.  It's  in  several  packages. 

MR.  MA:  How  accurate  can  the  data  display  of  the  profile  of  the  errors  be? 

MR.  DEFORGE:  Basically  we  take  the  position  that  is  user-definable. 

MR.  MA:  I guess  that  goes  with  digital  limitation,  right? 

MR.  DEFORGE:  Absolutely.  For  instance,  if  you  want  to  look  at  a circular  interpolated  move  in  the 
motion,  we  all  know  that  it's  broken  down  as  a series  of  linear  moves.  That's  user-definable  in  our 
software.  How  many  segments  do  you  want  to  divide  this  particular  move  into?  What  is  the  size  of  that 
segment?  You  can  go  with  a very  small  setting,  just  like  the  machine  tool,  but  you're  going  to  bog  the 
system  down.  The  same  thing  goes  with  the  rendering.  We  have  the  capability  of  setting  tolerance  levels 
for  the  Boolean  operations  for  combining  different  features.  It's  user  definable.  You  could  set  them  to 
zero,  meaning  you  want  to  represent  every  single  math  subtraction,  or  we  could  combine  some  of  those 
that  don't  make  a difference.  It  depends  on  what  kind  of  accuracies  you  want  to  get  out  of  the  system  at 
any  given  time. 

With  respect  to  CMM  technology,  that's  being  market  driven.  We  have  to  look  at  other  types  of 
measuring  technologies  that  are  currently  being  used,  and  is  CMM  actually  the  most  effective,  especially 
when  you  look  at  non-contact  type  measuring  devices  that  are  out  there.  That's  going  to  be  completely 
market  driven  from  our  point. 

MR.  ESTERLING:  I want  to  give  you  a sense  of  the  differences  between  what  is  available  out  there.  One 
of  the  really  good  things  that  Deneb  does  very  well,  is  modeling  a whole  machine  tool  environment.  But 
there  is,  perhaps,  a price  to  be  paid  by  modeling  the  whole  complex.  When  you  get  down  to  the  micro 
level  of  material  removal,  I would  argue  that  we  do  things  faster,  cheaper,  better  than  ever.  But  our 
corporate  philosophy  is  what  is  happening  at  the  tool  tip  itself.  That's  really  where  we  have  focused.  In 
the  same  sense  of  setting  tolerances,  we  don't  let  the  user  set  tolerances.  We  require  that  our  software 
deliver  the  kind  of  machine  tool  tolerance  we  expect  at  the  shop  floor  which  are  a few  micron  type 
tolerances.  We  start  out  with  that  by  saying,  "This  is  what's  required,"  and  typically  it's  not  so  much 
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processing  time;  in  our  model  it's  more  RAM  dependent.  If  you  don't  have  enough  available  RAM  you're 
going  to  start  going  off  from  the  hard  disk  and  then  all  hell  breaks  loose  in  terms  of  processing.  But,  as 
long  as  you're  staying  within  the  RAM  environment,  our  processing  time  is  not  affected  due  to  (1)  our 
modeling  system  and  (2)  our  avoidance  of  the  traditional  CAD  type  systems. 

MR.  JOHNSON:  How  do  you  characterize  the  non-uniformity  of  the  surface?  Do  you  do  that? 

MR.  ESTERLING:  Yes. 

MR.  JOHNSON:  What  kind  of  specification  do  you  use  for  that? 

MR.  ESTERLING:  We  don't  use  a polyhedral  system.  One  of  the  problems  of  the  polyhedral  systems  and 
why  we  abandoned  it  is  because  of  the  problem  of  speed  and  accuracy  and  the  trade-off  from  that.  We 
could  pull  some  really  horrendous  parts  together.  We  just  went  through  a benchmark  with  a fairly  large 
part  with  roughly  a tenth  or  two-tenths  of  a millimeter  in  depth  and  a one  meter  size.  That's  our  job,  to 
deliver  a virtual  CNC.  How  we  do  it  isn't  our  job  to  tell  you;  it's  our  job  to  simply  say  we're  doing  it. 

MR.  JOHNSON:  It's  all  internal,  so  you  wouldn't  export  that  data  to  a customer? 

MR.  ESTERLING:  No.  What  we  were  talking  about  with  Alkan  here,  is  that  we  also  need  to  provide 
hooks  so  that  we  can  export  it.  No  one  would  want  to  fool  with  our  model.  I mean,  it's  not  a CAD-like 
model.  It's  only  useful  for  a CAM  type  environment  where  you  work  in  great  large  numbers  of  Booleans, 
tens,  hundreds,  millions  of  Booleans,  at  very  high  accuracy.  That's  what  it's  tuned  for.  What  we  need  to 
do  is  to  take  that  model  we  have  and  export  it  a more  traditional  sort  of  CAD  type  format.  Deneb  is  ahead 
of  us  there.  They  provide  several  hooks  already.  This  is  something  which  we  are  developing  and  fairly 
shortly  will  have  it  out. 

QUESTION:  Is  there  any  accuracy  loss  in  doing  that  translation  to  export? 

MR.  DEFORGE:  If  you're  doing  translations  there  is  the  potential  for  accuracy  loss,  because  just  in 
setting  up  parameters  for  both  IGES  and  STL  export  translations.  If  you're  looking  at  direct  interfaces, 
that  potential  is  minimized. 

MR.  ESTERLING:  If,  for  example,  the  first  type  of  format  we  would  export  to  is  Stereo  Lithography 
(STL)  format,  which  is  basically  just  a huge  number  of  triangles  floating  in  space.  The  advantage  of  it  is 
it's  an  incredibly  brain-dead  way  to  sort  of  describe  a solid  system.  It's  also  one  which  is  used.  I mean 
IGES  like  standards  have  never  really  come  along  and  developed  a universal  standard  for  a solid  system. 
Whereas  STL  has  come  in  and  it's  basically  one  that's  used  by  everyone  for  its  simplicity.  But  there  is  a 
trade-off  with  STL.  If  you're  doing  that  kind  of  a format,  the  file  size  you're  dealing  with,  is  strictly 
related  to  the  accuracy  you're  imposing.  But  it's  simple,  so  we  love  it.  The  export  to  that  is  real  simple. 

MR.  DONMEZ:  I'd  like  to  move  onto  other  topics  now.  I'd  like  talk  briefly  about  what  are  our  future 
needs.  I marked  up  some  of  the  action  items  for  us.  One  of  them  is  starting  the  data  dictionary,  as  we 
talked  about  earlier  and  starting  a web  site  to  do  the  communication  and  the  comment  exchange.  We  will 
put  the  proposed  data  formats  that  Hans  presented  yesterday  on  that  web  site  so  that  we  can  get  more 
detailed  comments  from  you  all. 
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We  haven't  really  finalized  the  sign  convention,  which  is  a very  important  issue.  I was  hoping  that  we 
would  have  more  discussions  into  it,  but  we  didn't  get  that  much  discussion.  But  I'd  like  everybody  to 
think  very  seriously  about  the  pros  and  cons  of  different  types  of  sign  conventions  basically,  part 
coordinate  frame  versus  machine  coordinate  frame,  and  how  to  use  them  properly. 

Another  action  item  for  us  is  to  provide  some  data  to  Deneb  so  that  they  can  start  playing  with  the  type  of 
simulation  that  we  were  talking  about  earlier. 

We  will  also  ask  for  comments  about  the  road  map  and  then,  based  on  that,  we  will  compile  and  present  a 
road  map  for  the  next  time. 

MR.  CHANDRASEKHARAN:  Are  we  going  to  have  the  time  to  submit  the  data?  Is  that  something  we 
want  to  decide  now,  or  do  we  want  to  wait  for  the  data  definitions  and  the  data  dictionary  to  go  through? 
Should  we  be  doing  them  in  parallel? 

MR.  DONMEZ:  The  earlier  we  start  submitting  data,  the  better. 

MR.  BLOMQUIST:  One  of  the  things  we  talked  about  yesterday  was  forming  a consortium  to  do  this  so 
that  we  don't  get  inundated  with  1 0,000  participants.  I think  we  should  do  that.  The  best  way  for  us  to  do 
that  is  through  a Cooperative  Research  and  Development  Agreement  (CRADA).  It  acts  as  a filter  for 
serious  people  only.  I don't  think  that  we  should  have  a requirement  of  being  a member  of  the  consortium 
to  participate  in  these  meetings.  We'll  just  have  that  wide  open.  But  actually  to  log  on  to  the  web  site, 
collaborate  with  us,  I think  we  ought  to  limit  that  to  the  members  of  the  consortium.  So  we'll  do  that. 

MR.  DONMEZ:  So,  as  an  action  item  then,  we  will  develop  a generic  CRADA  and  send  it  out  to  people 
for  them  to  review  and  finalize. 

QUESTION:  What's  the  status  of  involving  the  automotive  manufacturers  in  this? 

MR.  DONMEZ:  We  have  sent  out  invitations  to  automotive  manufacturers  for  this  meeting.  We  didn't 
get  any  positive  response.  As  I mentioned  earlier,  one  of  the  comments  from  our  last  workshop  was  that 
we  need  to  involve  small  manufacturers,  machine  tool  builders,  and  automotive  industry.  Those  were  the 
lacking  components.  We  visited  NTMA,  the  National  Tooling  and  Manufacturing  Association,  and 
presented  our  views  and  plans  and  we  were  basically  told  that  we  need  to  talk  to  individual  small 
companies,  and  one  of  the  advanced  small  companies,  in  order  for  them  to  get  some  excitement  and 
participate.  And  we  haven’t  been  able  to  reach  them  yet. 

As  far  as  the  machine  tool  builders,  we  constantly  send  them  information  and  invitations  and  so  far  we 
haven't  gotten  much  response. 

If  any  of  you  can  help  us  bring  more  of  those  companies  on  board  that  would  be  very  appreciated. 

MR.  CHANDRASEKHARAN:  Do  you  think  the  auto  companies  are  not  jumping  on  board  because 
they're  still  more  focused  on  transfer  lines,  and  is  that  an  issue? 

MR.  DONMEZ:  I believe  it's  somewhat  of  an  issue.  Yes.  But  I would  have  thought  that  their  tech  center 
people  would  be  looking  at  it  more  closely. 
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MR.  DEFORGE:  We  have  some  contacts  that  we'll  make  a few  phone  calls. 

MR.  BLOMQUIST:  I think  a more  realistic  contact  with  the  automobile  industry  is  the  tier  suppliers.  If 
anybody  has  good  contact  with  the  tier  suppliers;  previous  work  with  the  big  three  on  other  issues  has  led 
me  to  believe  it's  highly  likely  you  could  get  them  to  participate  a lot  more  than  the  big  three. 
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WORKSHOP  SUMMARY 
R.  McClure 


Our  economic  future  depends  on  our  ability  to  create  a manufacturing  complex  that  has  the  characteristics 
of  competitiveness  and  rapid  response.  The  first  thing  I think  we  need  to  understand  is  the  process  by 
which  anything  is  bought  and  sold,  particularly  something  like  a machine  tool. 

The  key  components  in  such  a transaction  are  a customer  and  a vendor.  As  recently  as  two  decades  ago, 
the  process  was  straightforward;  Joe,  at  Boeing,  called  Sam,  at  Cincinnati  Milacron,  and  ordered  a bunch. 
In  the  late  '60s  Lawrence  Livermore  National  Laboratory  ordered  a Sundstrand  OM-3,  one  of  the  first,  and 
we  were  required  that  it  should  be  done  according  to  a detailed  specification.  However,  we  did  not  know 
what  the  capability  of  the  OM-3  was.  The  Atomic  Energy  Commission  had  another  OM-3  at  one  of  its 
other  facilities.  So,  a team  was  sent  there  and  they  measured  it  extensively  and  discovered  that  it  was 
pretty  good.  Sundstrand  built  fine  machines  in  that  period. 

There  were  a couple  of  things  that  didn't  fit  our  needs,  like  the  spindle  growth  on  the  trunnion-carried 
spindle,  so  in  our  order  for  a new  machine  we  asked  for  some  special  adaptations  such  as  putting  a water- 
jacket  around  the  spindle.  Of  course,  they  charged  us  extra  for  that.  But  what  was  interesting  was  that 
they  also  charged  us  about  ten  percent  of  the  cost  of  the  machine  just  to  work  to  the  specification. 

Eight  years  ago  I went  to  work  for  a machine  tool  company  and  now  I understand  why  Sunstrand  asked 
for  so  much  extra  money.  They  were  scared  of  that  kind  of  specification.  And,  as  it  turned  out,  our 
specification  caused  them  a lot  of  trouble,  time  and  money.  The  machine  sat  on  Sundstrand's  floor  for  14 
months  while  LLNL's  people  tested  it.  During  this  time  Sundstrand  had  to  make  modifications  in  order  to 
meet  the  specification.  They  even  had  to  make  modifications  to  the  modifications  they  had  previously 
made  since  they  had  built  the  machine  that  LLNL  had  previously  tested.  Between  these  two  machines, 
modifications  had  been  made  that  had  changed  the  machine's  characteristics  in  the  wrong  direction.  For 
example,  someone  had  decided  that  a motor  would  be  better  inside  the  casting  than  outside.  It  took  us  four 
months  to  find  out  that  it  was  the  reason  for  the  changes  in  thermal  characteristics  from  those  of  the  first 
machine.  The  fix  was  easy  but  took  a long  time  to  find  it. 

During  that  time,  Boeing  bought  an  OM-3  approximately  every  month.  At  least  1 5 were  sold  while  we 
were  still  trying  to  make  our  machine  meet  our  specifications.  But,  at  no  time  was  there  any  interest  in 
sharing  data  or  experiences  between  LLNL  and  Boeing.  In  fact,  I don't  think  Sundstrand  was  particularly 
interested  in  anything  but  getting  our  machine  off  their  floor  and  collecting  their  money.  I don't  know 
what  the  Boeing  machines  are  doing  now  but  LLNL  no  longer  has  its  machine.  It  would  have  been 
interesting  to  compare  all  of  those  machines  at  the  beginning. 

You've  got  the  vendor  and  the  customer  trying  to  talk  to  each  other  by  means  of  Joe  and  Sam.  Joe  and  Sam 
have  a very  difficult  problem  to  solve.  Joe  has  a part  drawing  and  he  didn't  care  less  about  what  the 
machine  was  like.  He  has  to  make  the  part  and  what  he  would  like  to  do  is  send  Sam  the  part  drawing  and 
have  him  guarantee  that  the  first  part,  and  every  part,  made  on  the  machine  will  be  within  spec  as  called 
out  on  the  drawing. 

The  vendor,  on  the  other  hand,  has  a model  number.  He'd  love  to  have  a purchase  order  that  says,  "Send 
me  one  each  Model  No.  X”— like  a SIP  6A— or  something  like  that.  That's  the  way  we  used  to  buy  and  in 
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most  cases  still  buy.  That's  the  vendor's  zero  risk  position.  The  customer's  zero  risk  position  is  the  part 
drawing.  Resolving  the  problem  of  two  possibly  mutually  exclusive  zero  risk  positions  is  the  purpose  of  a 
specification. 

There  are  some  other  people,  though,  who  can't  be  ignored  who  are  involved  in  the  process  of  developing 
a specification.  First,  there  are  civil  authorities.  These  are  the  guys  who  tell  you  that  you  can't  use  Freon 
in  your  manufacturing.  Civil  authorities  now  have  significant  influence  on  the  buying  and  selling  process. 
And  there  are  technical  authorities.  These  are  the  guys  who  write  the  standards  upon  which  a specification 
is  based.  National  and  international  standards  prescribe  how  to  measure  the  characteristics  that  are 
required  in  the  specification.  Without  standardized  language  and  procedures,  the  customer  and  vendor  are 
unable  to  talk  to  each  other  except  with  part  drawings  and  model  numbers. 

Somewhere  in  the  buyer's  chain  is  a product  manager.  This  is  a guy  who  has  the  responsibility  for 
bringing  a product  into  being,  like  the  guy  who  brought  the  777  into  being.  I don't  know  what  happened  to 
him,  he  got  transferred  the  day  of  the  first  flight. 

But  he  was  the  product  manager  and  he  had  to  bring  that  machine,  that  airplane,  onto  the  market  at  a 
specified  time  within  a certain  budget  and  it  had  to  perform  a certain  way. 

There  is  a product  manager  behind  all  of  these  chains  and  we've  got  to  take  him  into  account  more  and 
more  as  we  get  into  virtual  enterprises  and,  as  you  all  know,  we've  been  talking  here  about  the  things  that 
are  necessary  to  make  such  enterprises  work. 

By  the  way,  my  definition  of  a specification  is  a finite  set  of  administrate  requirements.  A lot  of  specs  go 
out  that  can't  be  administered.  There  are  plenty  of  things  on  a drawing.  A drawing  is  a specification.  But 
how  many  things  on  a drawing  actually  get  measured?  If  it's  not  administrate,  you  have  to  bluff.  But 
manufacturing  is  a series  of  bluffs,  isn't  it? 

We  make  the  assumption  that  the  drawing  conveys  all  the  information  necessary  to  make  a part,  but  the 
truth  is  that  it  doesn't.  A drawing  is  the  second  stage  of  a series  of  bluffs  that  occur  between  the 
conception  of  a product  and  its  manufacture.  The  guy  who  conceives  the  part,  and  what  it's  supposed  to 
do,  goes  to  the  draftsman  and  bluffs  him  into  believing  that  he  knows  what  he  wants.  He  probably  doesn't, 
completely.  The  draftsman  takes  incomplete  information  and  transforms  that  into  a drawing,  takes  it  to  a 
shop  and  tries  to  convince  the  machinist  he  knows  what  he's  doing.  The  machinist  makes  the  part  and  he 
presents  it  to  an  inspector  and  tries  to  convince  him  he  knew  what  he  was  doing.  And  then  the  inspector 
inspects  it  and  tries  to  convince  his  management  that  he  knew  what  he  was  doing.  If  you  look  at  any  of 
those  processes  very  carefully  you  find  it  isn't  true.  We  somehow  get  along,  but  how?  By  human 
intervention? 

Let  me  talk  for  a moment  about  this  product  manager.  He's  got  some  questions  that  he  has  to  answer. 

He's  got  a new  product-let's  change  industries— let's  say  it’s  a new  contact  lens.  And  this  is  a contact  lens 
that  not  only  gives  support  to  an  older  person  who  needs  bifocals,  but  also  has  astigmatism.  When  you 
look  at  the  Zemike  coefficients  of  something  like  that  you  find  that  it  is  really  difficult  to  make.  But  isn't 
that  typical  of  a new  product— it  may  have  never  been  made  before— that's  why  it's  a new  product 

So,  can  it  be  made?  That's  the  first  question.  Then,  how  can  it  be  made?  Then,  how  can  it  be  made  at  a 
cost  that's  acceptable  and  competitive?  Finally,  an  important  question  to  a product  manager,  once  all  these 
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questions  are  answered  and  we  are  in  production,  how  can  we  keep  the  production  system  from  deviating 
or  breaking  down?  Maybe  that’s  what  the  former  777  product  manager  is  doing  now,  making  sure  the 
system  he  set  up  doesn’t  get  out  of  control. 

I'd  like  to  carry  this  theme  one  step  further,  and  I labeled  this  "Goal".  In  the  last  meeting  we  talked  about 
our  basic  challenge  which  is  to  cope  with  the  development  of  a new  manufacturing  paradigm.  Whether 
you  call  it  "agile"  or  "virtual"  or  something  else,  the  facts  are  that  people  don't  want  to  own  factories  and 
they  don't  want  to  employ  people.  There  is  too  much  bother  with  harassment  lawsuits  and  benefits  and 
such.  So,  the  product  manager  will  minimize  all  that  by  contracting  work  out.  But,  he  has  still  to  make 
sure  that  any  vendor  produces  on  schedule  and  delivers  a satisfactory  product-all  of  his  vendors— and  they 
could  be  in  Europe,  the  U.S.,  China  or,  soon,  anywhere  in  the  world.  At  the  same  time,  he  has  to  arrange 
for  somebody— maybe  he  owns  a factory,  maybe  he  doesn't— to  assemble  all  of  this  and  package  it  and  ship 
it  to  customers.  And  he  has  to  depend  on  certain  functional  resources,  some  of  which  we've  been 
discussing  in  these  meetings. 

This  is  not  an  exhaustive  list,  but: 

Data.  He  has  to  have  data  with  which  you  can  make  decisions  about  how  to  make  something.  That  data 
has  to  conform  to  some  models  and  his  models  are  pretty  crude  at  this  stage.  The  kind  of  models  you  are 
talking  about  in  these  meetings  are  a lot  more  sophisticated  than  the  ones  that  managers  now  use  to  make 
decisions. 

And,  you  need  the  hardware— the  computers— the  people  and  the  natural  resources. 

We  haven't  talked  about  the  issue  of  people  much,  but  you  can't  ignore  it.  One  of  the  biggest  problems  we 
have  is  that  the  number  of  people  who  are  competent  to  even  be  here  and  have  this  conversation  is  pretty 
small  and  this  whole  enterprise  won't  go  anywhere  until  that  population  increases. 

Finally,  natural  resources.  You've  got  to  have  a source  of  stuff. 

Talking  about  specifications,  we  have  been  talking  about  "data"  in  two  ways:  data  with  which  to  assess 
how  good  a product  is  and  data  with  which  to  write  a specification.  In  the  process  of  writing  a 
specification  you  have  to  take  into  account  all  possible  characteristics.  We  could  list  all  kinds  of 
characteristics.  Hans  [Soons]  has  done  that  in  the  work  he's  described  and  his  list  is  probably  not 
exhaustive.  It's  scary  when  you  look  at  Hans'  list.  But,  how  many  parameters  have  to  be  controlled  and 
optimized? 

In  writing  a specification  it  is  necessary  to  take  the  set  of  all  possible  characteristics  and  pass  it  through  a 
functional  filter  to  obtain  a list  that  must  be  included  in  a given  specification.  This  filter,  in  the  past,  was 
provided  primarily  by  skilled  people  who  could  tell  you,  for  example,  what  a good  grinder  could  do.  You 
can  still  go  out  into  the  shop  and  ask  someone  "How  round  can  you  grind  something?"  and  you'll  get  the 
reply  "Fifty  millionths."  Skill  and  experience  were  used  and  are  still  used  to  do  this  filtering  with  very 
little  hard  data.  Very  few  people  go  out  and  actually  measure  something,  like  LLNL  did  in  the  case  of  the 
purchase  of  the  Sundstrand  OM-3,  and  try  to  create  a specification  on  that  basis. 

We're  encouraging  people  now  to  develop  error  budgets  as  a better  means  of  filtering.  But  there  is  no  one 
way  of  developing  an  error  budget.  Oak  Ridge  doesn't  talk  about  an  error  budget  in  the  same  way  that 
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LLNL  does.  However,  differences  are  mostly  method,  not  the  basic  idea.  Perhaps  we  can  use  simulation 
as  a filter.  Indeed,  that  seems  to  be  one  of  the  important  applications  of  the  simulation  work  that  has  been 
discussed  in  these  meetings. 

If  you're  going  to  establish  a total  system  you  need  a process  model,  and  I think  I heard  you  say  that  it's 
where  you  are  headed.  I believe  you  want  to  include  everything  up  to  and  including  the  assembly.  That 
might  give  the  product  managers  a way  of  making  decisions  and  of  controlling  the  process. 

A discussion  took  place  yesterday  about  corporate  policy,  and  I saw  a lot  of  horns  being  pulled  in  when 
the  question  was  asked,  "Will  your  company  do  this  [share  data]?"  I've  run  into  that  before,  in  many 
forms,  and  I suggest  that  it  needs  to  be  addressed  and  your  management  has  to  be  sold.  You  need  to  go 
back  to  your  companies  and  explain  to  them  why  it's  good  for  them  to  "do  this".  Or  the  group  here  or 
someone  else  needs  to  do  the  selling  of  these  ideas.  You  ought  to  point  out  that  there  are  some  good 
things  that  can  happen.  This  data  base-through  some  kind  of  pooling— could  help  to  validate  procedures. 

For  example,  instead  of  being  ignorant  of  what  the  other  knew,  today  it  should  be  possible  for  LLNL  and 
Boeing  to  share  data  about  the  OM-3s  they  were  each  buying  instead  of  being  studiously  ignorant  of  each 
other  as  they  were  30  years  ago.  With  such  exchanges  you  would  not  only  be  able  to  validate  data,  you 
would  able  to  validate  procedures. 

The  Web  is  clearly  the  way  to  expedite  the  exchange  of  data  and  procedures.  Creation  of  such  a Web  page 
should  be  one  of  the  highest  priorities  of  this  project.  The  Website  could  have  links  to  other  sites  where 
people  could,  perhaps  for  a fee,  use  your  software  to  perform  their  own  analyses,  compare  with  other 
people's,  and  certainly  validate  the  procedures  related  to  buying  equipment.  This  could  help  avoid  the 
pitfalls  that  would  result  when  people  get  the  wrong  data  and  perform  the  wrong  analyses.  There  are  a lot 
of  neat  things  being  offered  in  the  metrology  area,  more  every  day.  But  you  have  to  be  careful  because 
instruments  don't  always  produce  the  same  results.  A good  example  is  the  experience  of  surface  finish 
instruments.  We  went  through  50  years  of  evaluation  to  get  to  a place  where  we  could  actually  control  the 
output  of  these  instruments  so  that  they  would  be  consistent  with  each  other  and  I don't  think  we're 
perfectly  satisfied  with  the  status  yet. 

With  such  exchanges,  we  are  bound  to  improve  our  procurements.  In  Europe,  value  engineering  has  been 
used  in  conjunction  with  other  procurement  procedures  to  improve  selection  processes.  Data  exchange 
could  add  substance  to  such  value  engineering. 

As  we  all  know,  vendor  control  is  key  to  the  successful  implementation  of  the  new  paradigm  of 
manufacturing.  ISO  9000  and  similar  procedures  are  becoming  increasingly  necessary.  But  ISO  simply 
says  what  should  be  in  place  not  how  it  works.  Technical  procedures  are  still  needed  and  they  need  to  be 
continuously  developed  and  improved.  The  existence  of  data  bases  like  that  discussed  in  these  meetings 
is  the  best  means  of  validating  data  and  procedures  and  most  expeditiously  improving  the  means  of 
controlling  virtual  enterprises. 

There  was  an  article  in  Manufacturing  Engineering  about  1 0 years  ago,  entitled  "Machine  Tool  Accuracies 
aren't  the  same.  It  showed  that  data  collected  under  a DIN  standard,  the  NMTBA  standard  or  the  Japanese 
standard  would  give  different  results.  That's  certainly  something  that  would  be  forced  to  improve  if  some 
collaboration  was  formed. 
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I have  some  advice  to  give  to  you.  Don't  mix  your  problems.  One  person  here  pointed  out  that  the 
designer  looks  at  this  subject  in  an  entirely  different  way  and  has  different  needs.  Another  pointed  out  that 
going  to  operate  a plant  also  has  unique  needs.  What's  the  maintainability  and  reliability?  What's  the  up 
time?  What's  the  through  put?  Please  try  to  concentrate  on  one  set  of  problems  at  a time,  otherwise  you 
will  try  to  solve  all  problems  simultaneously  and  progress  will  be  slow. 

Having  raised  the  maintenance  issue,  I am  reminded  of  NIST's  work  on  "interim  testing"  of  coordinate 
measuring  machines.  An  artifact  is  used  as  a quick  way  of  assessing  whether  something  has  changed  or 
not.  This  kind  of  testing  does  not  provide  detailed  accuracy  and  performance  characteristics  but  just 
enough  data  to  determine  that  something  has  changed.  This  kind  of  information  is  valuable  in  system 
maintenance. 

Interim  testing  is  a form  of  an  old  method  of  metrology  that  is,  I believe,  being  revived  and  brought  up  to 
date  and  now  is  called  "Comparative  Metrology".  Artifacts  are  used  in  comparators  to  validate  parts  in 
process.  Let's  ask  the  Boeing  people  how  many  parts  are  examined  by  comparison? 

BOEING  PERSON:  Not  many. 

MR.  MCCLURE:  I disagree,  I would  guess  around  90  percent.  You  must  look  closely  at  what  is  actually 
happening.  I will  give  you  an  example.  Grinders  are  difficult  things  to  support  in  the  field  because  the 
grit  in  the  wheels  give  different  surface  patterns,  depending  on  a lot  of  conditions.  Everyone  who  makes  a 
grinder  runs  into  a customer  who  calls  him  up  and  says,  "I've  got  a new  machine  standing  right  next  to  my 
old  machine  and  the  parts  look  different.  What's  wrong  with  the  new  machine?"  I've  gone  through  this 
situation  where  I have  showed  them  numerically  and  scientifically,  according  to  all  the  standard  ways  of 
measuring,  that,  if  anything,  the  new  part  is  better  than  the  old  one.  He  won't  accept  that.  "It's  different, 
so  it's  wrong".  He's  applying  a comparative  form  of  go-no  go  inspection. 

Comparative  metrology  is  used  now  and  will  become  more  important  to  effective  process  control  in  the 
future.  It  will  especially  be  important  to  the  role  of  coordinate  measuring  machines,  40  percent  of  which 
are  now  underutilized  (according  to  John  Bosch,  formerly  with  Sheffield).  These  machines  did  not  live  up 
to  someone's  expectation  which  typically  was  that  they  were  absolute  gages.  But  because  of 
environmental  and  other  effects  they  are  not  absolute  gages.  But  I suggest  to  you  that  they  make 
magnificent  comparators.  They  can  collect  and  process  a large  amount  of  data  in  a short  time  and  fit 
nicely  into  comparative  metrology  schemes.  Comparative  Metrology,  briefly,  uses  standard  or  certified 
artifacts.  The  artifacts  are  certified  by  some  agency  like  NIST.  Comparative  metrology  was  virtually  the 
only  way  of  inspecting  before  there  were  standards  and  people  the  likes  of  Eli  Whitney.  The  artisan  made 
a part  that  he  used  to  compare  with  all  subsequent  parts. 

Comparative  metrology  needs  to  be  developed,  especially  in  the  application  of  coordinate  measuring 
machines  as  process  controllers. 

Finally,  some  conclusions.  The  best  thing  I've  heard  about  in  the  past  two  days  is  the  discussion  about  a 
Website.  I think  this  answers  the  question  about  how  to  get  started.  And,  to  get  started,  it  would  be 
appropriate  to  address  some  issues  that  can  be  easily  defined. 

There  is  the  question  of  standards.  A glossary  is  a standard.  ISO  230-1  is  a pre-existing  set  of  definitions 
that  is  supposed  to  be  applied  to  the  inspection  of  machine  tools.  You  could  start  with  that.  By  the  way. 
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some  of  those  words  need  to  be  redefined.  The  old  glossary  contains  words  that  are  no  longer  valid.  You 
could  also  include  the  Sign  Convention  which  obviously  should  be  applied  to  all  machine  tool  accuracy 
standards. 

We  need  more  competent  people. 

We  need  data.  I don't  know  any  other  product  that  we  know  less  about  than  machine  tools.  Builders  don't 
test  them  thoroughly,  they  depend  mostly  on  process  control. 

I present  the  word  "taxonomy"  here  because  we  tend  to  get  bogged  down  in  language  difficulties  and  prior 
fixed  notions  and,  I believe,  we  are  over-concentrating  on  machine  tools.  Personally,  I'm  not  convinced 
that  there  is  a machine  tool  product  anymore.  I'm  not  sure  that  there  is  a valid  machine  tool  industry. 

Most  of  the  machines  being  built  today  in  the  U.S.  are  "specials".  Standard  products  are  being  made  in 
other  countries  because  of  cheap  labor.  In  our  new  distributed  manufacturing  process  there  are  probably 
going  to  be  processes  ranging  from  glass-blowing  to  machining  and  that's  why  I believe  we  need  a 
taxonomy. 

There  was  a fellow  at  Brigham  Young  University  who,  in  the  late  '70s,  early  '80s,  who  came  up  with  a 
taxonomy  for  manufacturing.  It  would  be  worthwhile  to  revisit  this  issue. 

For  a machine  tool  database,  you  need  storage  and  retrieval,  and  we've  spent  a lot  of  time  in  these 
meetings  on  that  subject.  Someone  has  to  maintain  it  once  it  exists  and  maintenance  doesn't  mean  just 
stocking.  Someone  has  to  be  dedicated  to  polishing  the  knobs,  grease  it  and  change  it  if  we  want  to  make 
improvements. 

Economic  issues  cannot  be  ignored.  The  ultimate  purpose  of  any  collection  of  information  is  to  allow 
someone  to  make  judgements  on  how  to  make  thousands  of  parts. 

There  was  a discussion  that  seemed  to  fizzle  because  of  embarrassment  or  shyness,  I don't  know  which. 
The  issue  was  who  was  going  to  own  and  operate  this  database,  particularly  what  is  the  role  of  the 
government.  Of  course,  if  you're  in  free  enterprise  you  don't  like  the  idea  of  the  government  owning  and 
operating  it.  However,  there  are  some  examples  of  past  successes  private  as  well  as  government.  There 
are  also  some  examples  of  failures.  Some  of  the  relatively  good  past  examples  are  the  Department  of 
Agriculture,  the  Bureau  of  Mines  and  the  National  Advisory  Committee  on  Aeronautics  (NACA). 

Without  the  Bureau  of  Mines  the  Materials  Handbook  would  not  exist. 

Pardon  me  for  referring  to  NIST  as  the  National  Bureau  of  Standards  or  NBS,  but  I want  to  emphasize  its 
original  role  as  keeper  and  supplier  of  standards. 

NACA  was  established  around  1915  as  a spin-off  from  the  Navy  as  a means  of  collecting  and 
disseminating  data.  As  a young  engineer  at  Boeing,  I worked  on  a problem  involving  landing  gear  spring- 
back.  The  only  data  I had  I found  in  old  NACA  Technical  Notes. 

NACA  became  NASA  with  a different  mission  and  I think  the  value  of  NASA  as  a source  of  information 
suffered.  The  primary  intent  of  NACA  was  to  provide  data  to  a fledgling  industry.  In  the  20's  and  30's 
companies  like  Boeing  and  Wright  were  too  weak  to  build  the  kinds  of  wind  tunnels  that  were  needed,  so 
NACA  built  them  and  the  industry  used  them.  The  elliptical  wing  and  laminar  flow  airfoils  were 
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developed  this  way  and  were  used  by  the  industry.  Now,  computer  simulations  have  largely  replaced  the 
wind  tunnels.  These  are  the  good  examples  of  government  support.  With  that,  I’ll  finish  my  summary. 
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